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Abstract 

The  presence  of  aliasing  makes  modular  verification  of  object-oriented  code  difficult.  If  multiple 
clients  depend  on  the  properties  of  an  object,  one  client  may  break  a  property  that  others  depend 
on.  We  have  developed  a  modular  verification  approach  based  on  the  novel  abstraction  of  object 
propositions,  which  combine  predicates  and  information  about  object  aliasing.  In  our  methodol¬ 
ogy,  even  if  shared  data  is  modified,  we  know  that  an  object  invariant  specified  by  a  client  holds. 
Our  permission  system  allows  verification  using  a  mixture  of  linear  and  nonlinear  reasoning.  This 
allows  it  to  provide  more  modularity  in  some  cases  than  competing  separation  logic  approaches, 
because  it  can  more  effectively  hide  the  exact  aliasing  relationships  within  a  module.  We  vali¬ 
date  our  approach  on  an  instance  of  the  composite  pattern  that  illustrates  our  system’s  practicality. 
We  implement  our  methodology  in  the  intermediate  verification  language  Boogie  (of  Microsoft 
Research),  for  the  composite  pattern  example. 


1  Introduction 


We  propose  a  method  for  modular  verification  of  object-oriented  code  in  the  presence  of  aliasing, 
i.e.,  the  existence  of  multiple  references  to  the  same  object.  The  seminal  work  of  Parnas  [22] 
describes  the  importance  of  modular  programming,  where  the  information  hiding  criteria  is  used 
to  divide  the  system  into  modules.  In  a  world  where  software  systems  have  to  be  continually 
changed  in  order  to  satisfy  new  (client)  requirements,  the  software  engineering  principle  of  modu¬ 
lar  programming  becomes  crucial:  it  brings  flexibility  by  allowing  changes  to  one  module  without 
modifying  the  others.  Since  Java  is  one  of  the  most  popular  programming  languages  used  in  indus¬ 
try,  our  verification  methodology  targets  a  Java-like  language.  The  formal  verification  of  modules 
should  ideally  follow  the  same  principle:  the  specification  and  verification  of  one  method  should 
not  depend  on  details  that  are  private  to  the  implementation  of  another  method.  This  means  that 
modular  verification  should  allow  classes  (i.e.,  modules)  to  be  verified  independently  from  each 
other.  An  important  instance  of  this  principle  comes  in  the  presence  of  aliasing:  if  two  methods 
share  an  object,  yet  their  specification  is  not  affected  by  this  sharing,  then  the  specification  should 
not  reveal  the  presence  of  the  sharing. 

We  introduce  the  notion  of  an  object  proposition  for  the  modular  verification  of  object-oriented 
code  in  the  presence  of  aliasing.  Object  propositions  combine  predicates  on  objects  with  alias¬ 
ing  information  about  the  objects  (represented  by  fractional  permissions).  They  are  associated 
with  object  references  and  declared  by  programmers  as  part  of  method  pre-  and  post-conditions. 
Through  the  use  of  object  propositions,  we  are  able  to  hide  the  shared  data  that  two  objects  have 
in  common.  The  implementations  of  the  two  objects  use  fractions  to  describe  how  to  access  the 
common  data,  but  this  common  data  need  not  be  exposed  in  their  external  interface.  Our  solution  is 
therefore  more  modular  than  the  state  of  the  art  with  respect  to  hiding  shared  data,  and  furthermore 
generalizes  systems  [3]  for  which  there  is  good  automated  tool  support. 

Our  main  contributions  are  the  following: 

•  A  verification  methodology  that  unifies  substructural  logic-based  reasoning  with  invariant- 
based  reasoning.  Linear  permissions  (object  propositions  where  the  fraction  is  equal  to  1) 
permit  reasoning  similar  to  separation  logic,  while  fractional  permissions  (object  proposi¬ 
tions  where  the  fraction  is  less  than  1)  introduce  non-linear  invariant-based  reasoning.  Un¬ 
like  prior  work  [5],  fractions  do  not  restrict  mutation  of  the  shared  data;  instead,  they  require 
that  the  specified  invariant  be  preserved. 

•  A  proof  of  soundness  in  support  of  the  system. 

•  Validation  of  the  approach  by  specifying  and  proving  partial  correctness  of  the  composite 
pattern,  demonstrating  benefits  in  modularity  and  abstraction  compared  to  other  solutions 
with  the  same  code  structure. 


2  Overview 

Our  methodology  uses  abstract  predicates  [21]  to  characterise  the  state  of  an  object.  We  embed 
those  predicates  in  a  logical  framework,  and  specifies  sharing  xx^ing  fractions  [5].  A  fraction  can  be 
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Figure  1 ;  Linked  queues  sharing  the  tail 


equal  to  1  or  it  can  be  less  than  1.  Fractions  are  useful  when  there  are  multiple  aliases  that  reference 
the  same  object  in  the  program.  With  the  help  of  fractions,  we  can  track  how  a  reference  is  allowed 
to  read  and  modify  the  referenced  object  and,  in  the  case  of  other  references  to  the  object,  how 
those  references  might  access  the  object. 

If  the  fraction  is  1,  it  grants  read/write  access  to  some  particular  fields  of  the  object  (depending 
on  the  fields  that  are  mentioned  in  the  accompanying  predicate).  If  the  fraction  is  less  than  I, 
there  might  be  other  references  that  also  have  read/write  access  to  the  same  object.  In  the  case 
of  fractions  less  than  1  to  be  usable,  they  must  guarantee  that  they  will  never  violate  some  object 
invariant,  expressed  as  a  predicate. 

Our  main  technical  contribution  is  the  novel  abstraction  called  object  proposition,  that  com¬ 
bines  predicates  with  aliasing  information  about  objects.  For  example,  to  express  that  the  object 
q  in  Figure  1  has  full  control  of  a  queue  of  integers  in  range  [0, 10],  we  use  the  object  proposition 

g@l  Range{0, 10). 

We  want  our  checking  approach  to  be  modular  and  to  verify  that  implementations  follow  their 
design  intent.  In  our  approach,  method  pre-  and  post-conditions  are  expressed  using  object  propo¬ 
sitions  over  the  receiver  and  arguments  of  the  method.  To  verify  the  method,  the  abstract  predicate 
in  the  object  proposition  for  the  receiver  object  is  interpreted  as  a  concrete  formula  over  the  cur¬ 
rent  values  of  the  receiver  object’s  fields  (including  for  fields  of  primitive  type  int).  Following 
F^ndrich  and  DeLine  [10],  our  verification  system  maintains  a  key  for  each  field  of  the  receiver 
object,  which  is  used  to  track  the  current  values  of  those  fields  through  the  method.  A  key  o./  — ?•  x 
represents  read/write  access  to  field  /  of  object  o  holding  a  value  represented  by  the  concrete  value 
X.  At  the  end  of  a  public  method,  we  pack  [7]  the  keys  back  into  an  object  proposition  and  check 
that  object  proposition  against  the  method  post-condition. 

As  a  simple  example,  we  consider  two  linked  queues  q  and  r  that  share  a  common  tail  p,  in 
Figure  1.  In  prior  work  on  separation  logic  or  dynamic  frames,  the  specification  of  any  method 
has  to  describe  the  entire  footprint  of  the  method,  i.e.,  all  heap  locations  that  are  being  touched 
through  reading  or  writing  in  the  body  of  the  method.  That  is,  the  shared  data  p  has  to  be  specified 
in  the  specification  of  all  methods  that  access  the  objects  in  the  lists  q  and  r.  Using  our  object 
propositions,  we  have  to  mention  only  a  permission  g@l  V alidQueue  (r@l...  respectively)  in  the 
specification  of  a  method  accessing  q  (or  r).  The  fact  that  p  is  shared  between  the  two  aliases  is 
hidden  by  the  abstract  predicate  V alidQueue. 

In  Section  4  we  discuss  this  example  in  more  detail  in  order  to  illustrate  the  technical  differ¬ 
ences  in  verifying  this  example  using  object  propositions  versus  prior  approaches. 
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3  Current  Approaches 

The  verification  of  object-oriented  code  can  be  achieved  using  the  classical  invariant-based  tech¬ 
nique  [2].  When  using  this  technique,  all  objects  of  the  same  class  have  to  satisfy  the  same  invari¬ 
ant.  The  invariant  has  to  hold  in  all  visible  states  of  an  object,  i.e.  before  a  method  is  called  on 
the  object  and  after  the  method  returns.  The  invariant  can  be  broken  inside  the  method  as  long  as 
it  is  restored  upon  exit  from  the  method.  This  leads  to  a  key  limitation:  the  specifications  that  can 
be  written  using  the  proof  language  and  the  verification  that  can  be  performed  are  limited.  This 
limitation  shows  itself  in  a  number  of  ways.  One  sign  is:  the  methods  that  can  be  written  for  each 
class  are  restricted  because  now  each  method  of  a  particular  class  has  to  have  the  invariant  of  that 
class  as  a  post-condition.  Another  sign  is  that  the  invariant  of  an  object  cannot  depend  on  another 
object’s  state,  unless  additional  features  such  as  ownership  are  added.  Leino  and  Midler  [23]  have 
added  ownership  to  organize  objects  into  contexts.  In  their  approach  using  object  invariants,  the 
invariant  of  an  object  is  allowed  to  depend  on  the  fields  of  the  object,  on  the  fields  of  all  objects 
in  transitively-owned  contexts,  and  on  fields  of  objects  reachable  via  given  sequences  of  fields.  A 
related  restriction  is  that  from  outside  the  object,  one  cannot  make  an  assertion  about  that  object’s 
state,  other  than  that  its  invariant  holds.  Thus  the  classic  technique  for  checking  object  invariants 
ensures  that  objects  remain  well-formed,  but  it  does  not  help  with  reasoning  about  how  they  change 
over  time  (other  than  that  they  do  not  break  the  invariant). 

Separation  logic  approaches  [21],  [8],  [6],  etc.  bypass  the  limitations  of  invariant-based  ver¬ 
ification  techniques  by  requiring  that  each  method  describe  its  footprint  and  the  predicates  that 
should  hold  for  the  objects  in  that  footprint.  In  this  way  not  all  objects  of  the  same  class  have  to 
satisfy  the  same  predicate.  Separation  logic  allows  us  to  reason  about  how  objects’  state  changes 
over  time.  On  the  downside,  now  the  specification  of  a  method  has  to  reveal  the  structures  of  ob¬ 
jects  that  it  uses.  This  is  not  a  problem  if  the  objects  in  the  footprint  are  completely  encapsulated. 
But  if  they  are  shared  between  two  structures,  that  sharing  must  be  revealed  when  transitioning 
between  the  “inside"  and  “outside"  of  the  encapsulating  abstraction.  This  is  not  desirable  from  an 
information  hiding  point  of  view. 

On  the  other  hand,  permission-based  work  [3],  [7],  [5]  gives  another  partial  solution  for  the 
verification  of  object-oriented  code  in  the  presence  of  aliasing.  By  using  share  and/or  fractional 
permissions  referring  to  the  multiple  aliases  of  an  object,  it  is  possible  for  objects  of  the  same  class 
to  have  different  invariants.  This  is  different  from  the  traditional  thinking  that  an  object  invariant 
is  always  the  same  for  all  objects.  What  share  and/or  fractions  do  is  allow  us  to  make  different 
assertions  about  different  objects;  we  are  not  limited  to  a  single  object  invariant.  This  relaxes  the 
classical  invariant-based  verification  technique  and  it  makes  it  much  more  flexible. 

Moreover,  developers  can  use  access  permissions  [3]  to  express  the  design  intent  of  their  pro¬ 
tocols  in  annotations  on  methods  and  classes.  Our  work  uses  fractional  permissions  [5]  (which 
are  similar  to  access  permissions  in  some  respects)  in  the  creation  of  the  novel  concept  of  object 
propositions.  The  main  difference  between  the  way  we  use  permissions  and  existing  work  about 
permissions  is  that  we  do  not  require  the  state  referred  to  by  a  fraction  less  than  1  to  be  immutable. 
Instead,  that  state  has  to  satisfy  an  invariant  that  can  be  relied  on  by  other  objects.  Our  goal  is 
to  modularly  check  that  implementations  follow  their  design  intent.  The  typestate  [7]  formulation 
has  certain  limits  of  expressiveness:  it  is  only  suited  to  finite  state  abstractions.  This  makes  it 
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unsuitable  for  describing  fields  that  contain  integers  (which  can  take  an  infinite  number  of  values) 
and  can  satisfy  various  arithmetical  properties.  Our  object  propositions  have  the  advantage  that 
they  can  express  predicates  over  an  infinite  domain,  such  as  the  integers. 

Our  fractional  permissions  system  allows  verification  using  a  mixture  of  linear  and  nonlinear 
reasoning,  combining  ideas  from  previous  systems.  The  existing  work  on  separation  logic  is  an 
example  of  linear  reasoning,  while  the  work  on  fractional  permissions  is  an  example  of  nonlinear 
reasoning.  In  a  linear  system  there  can  be  only  one  assertion  about  each  piece  of  state  (such  as 
each  field  of  an  object),  while  in  a  nonlinear  system  there  can  be  multiple  mentions  about  the  same 
piece  of  state  inside  a  formula.  The  combination  of  ideas  from  these  two  distinct  areas  allows  our 
system  to  provide  more  modularity  than  each  individual  approach.  For  example,  in  some  cases  our 
work  can  be  more  modular  than  separation  logic  approaches  because  it  can  more  effectively  hide 
the  exact  aliasing  relationships. 

4  Example:  Queues  of  integers 

In  Figure  2,  we  present  a  class  that  defines  object  propositions  which  are  useful  for  reasoning 
about  the  correctness  of  client  code  and  about  whether  the  implementation  of  a  method  respects 
its  specification.  Our  specification  logic  is  based  on  linear  logic  [12],  a  simplification  of  separation 
logic  that  retains  the  advantages  of  separation  logic’s  frame  rule'.  Object  propositions  are  thus 
treated  as  resources  that  may  not  be  duplicated,  and  which  are  consumed  upon  usage.  Pre-  and 
post-conditions  are  separated  with  a  linear  implication  ^  and  use  multiplicative  conjunction  (0), 
additive  disjunction  (©)  and  existential/universal  quantifiers  (where  there  is  a  need  to  quantify  over 
the  parameters  of  the  predicates). 

Newly  created  objects  have  a  fraction  of  1,  and  their  state  can  be  manipulated  to  satisfy  different 
predicates  defined  in  the  class.  At  the  point  where  the  fraction  to  the  object  is  first  split  into  two 
fractions  less  than  1  (see  Figure  8),  the  predicate  currently  satisfied  by  the  object’s  state  becomes 
an  invariant  that  the  object  will  always  satisfy  in  future  execution.  Different  references  pointing  to 
the  same  object  will  always  be  able  to  rely  on  that  invariant  when  calling  methods  on  the  object. 

A  critical  part  of  our  work  is  allowing  clients  to  depend  on  a  property  of  a  shared  object.  In 
this  queue  example,  clients  depend  on  the  shared  Link  items  being  in  a  consistent  range.  Other 
methodologies  such  as  Boogie  [1]  allow  a  client  to  depend  only  on  properties  of  objects  that  it 
owns.  Our  verification  technique  also  allows  a  client  to  depend  on  properties  of  objects  that  it 
doesn’t  (exclusively)  own. 

To  gain  read  or  write  access  to  the  fields  of  an  object,  we  have  to  unpack  it  [7].  When  we 
unpack  an  object  proposition  (with  a  fraction  of  1  or  with  a  fraction  of  less  than  1),  we  gain 
modifying  access.  After  a  method  finishes  working  with  the  fields  of  a  shared  object,  our  proof 
rules  in  Section  6  require  us  to  ensure  that  the  same  predicate  as  before  the  unpacking  holds  of  that 
shared  object.  If  the  same  predicate  holds,  we  are  allowed  to  pack  back  the  shared  object  to  that 
predicate.  Since  for  a  unique  object  (an  object  that  is  referenced  with  a  fraction  of  1),  there  is  only 
one  reference  in  the  system  pointing  to  it  and  no  risk  of  interferences,  we  don’t  require  packing 

'  we  believe  our  methodology  can  be  applied  in  a  separation  logic  setting  as  well,  but  leave  this  extension  to  future 
work,  as  linear  logic  is  sufficient  to  express  our  ideas. 
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class  Link  { 

int  val; 

Link  next; 

predicate  Range  (int  x,  int  y)  =3v,o,k 
val— >  V  0  next— )■  o 
i^v>x<Siv<Y 
0  [o@fc  Range{x,y)  ©  o  ==  null] 

predicate  UniRange(int  x,  int  y)  =  o 
val^  V  ©  next— >■  o  ©  r>x©r<y 
©  [o@l  UniRange{x,y)  ©  o  ==  null] 

void  addModuloll (int  x) 

this@k  Range{0, 10)  ^  this@k  Range{0, 10) 

{val  =  (val  +  x) %  11; 
if  (next!=null)  {next . addModuloll (x) ; } 

} 


void  add (int  z) 

V  x:int,  y:int,  x<y  .this@l  UniRange{x,y) 
—o  this@l  UniRange{x  +  z,y  +  z) 
{val  =  val  +  z; 

if  (next!=null)  { next . add ( z ); } 


} 


Figure  2:  Link  class  and  range  predicates 


5 


to  the  same  predicate  for  unique  objects.  We  avoid  inconsistencies  by  allowing  multiple  object 
propositions  to  be  unpacked  at  the  same  time  only  if  the  objects  are  not  aliased,  or  if  the  unpacked 
propositions  cover  disjoint  fields  of  a  single  object. 

The  predicate  Range(int  x,  int  yj  in  Figure  2  ensures  that  all  the  elements  in  a  linked  queue 
starting  from  the  current  Link  are  in  the  range  [x,  y\.  The  object  proposition  mentions  o@A:,  thus 
requiring  the  existence  of  a  fraction  giving  access  to  each  Link  of  the  queue.  In  contrast,  the 
predicate  UniRange(int  x,  inty)  requires  the  presence  of  a  unique  permission  to  all  elements  in  the 
queue.  These  restrictions  mean  that  the  only  method  that  can  be  called  on  a  shared  Link  object 
satisfying  invariant  Range{0, 10)  is  addModulol  1 .  The  specification  of  the  addModuloll(int  x) 
method  is  the  only  one  that  does  not  break  the  invariant.  If  the  programmer  wants  to  modify  some 
value  in  the  queue  using  the  add( int  z)  method,  the  queue  must  be  accessed  through  a  fraction  of  1 . 

Given  a  pre-condition  and  a  desired  post-condition,  expressed  as  logical  formulas  over  object 
propositions,  the  proof  rules  in  Section  6  are  used  to  verify  a  segment  of  code.  There  is  a  proof 
rule  for  each  expression  form,  as  well  as  a  rule  for  sequencing  statements/expressions  (technically 
with  a  let  expression  in  our  formalism).  The  soundness  of  the  proof  rules  (defined  later)  means 
that  given  a  heap  that  satisfies  the  pre-condition  formula,  a  program  that  typechecks  and  verifies 
according  to  our  proof  rules  will  execute,  and  if  it  terminates,  will  result  in  a  heap  that  satisfies 
the  postcondition  formula.  While  our  proof  rules  are  not  complete,  they  are  sufficient  to  verify  an 
interesting  set  of  programs  and  properties,  including  the  examples  in  this  paper. 

We  show  some  client  code  and  its  verification  using  object  propositions: 


Link  la  =  new  (Link  (3,  null) , Range (0, 10) ) ; 
unpacked{la,  1)  ®  o  .  la.val  — >  ®  la.next  — >■  o 

0  V  ==  3  0  0  ==  null 
la@l  Range{0, 10) 

la@^  Range{0, 10)  0  la@^  Range{0, 10) 

Link  p  =  new  (Link (6,  la) , Range ( 0 , 1 0 )) ; 
p@l  Range{0, 10)  0  la@^  Range{0, 10) 

Range{0, 10)  0  Range{0, 10) 

Link  q  =  new  (Link(l,  p ),  Range ( 0 ,  1 0  ))  ; 

q@l  Range{0, 10)  0  p@^  Range{0, 10) 

Link  r  =  new  (Link (8,  p) , Range (0, 10) ) ; 
r@l  Range{0, 10)  0  g@l  Range{0, 10) 

r@^  Range{0, 10)  0  r@^  Range{0, 10)  ^  q@l  Range (0,10) 
r . addModulol 1 ( 9) ; 

q@l  Range{0, 10)  0  r@^Range{0, 10) 

q@^  Range(0, 10)  0  q@^  Range{0, 10)  0  Range{0, 10) 
q . addModulol 1  ( 7 )  ; 

g(Q)l  Range{0, 10)  0  Range{0, 10) 
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When  first  creating  object  la,  we  get  an  unpacked  object  proposition  with  a  fraction  of  1,  along 
with  keys  for  each  of  the  helds  and  assertions  about  the  field  values.  We  can  pack  these  permissions 
up  into  the  predicate  Range{0, 10),  then  split  the  fraction  of  1  into  two  half  fractions,  as  we  have 
to  pass  a  permission  to  la  to  the  constructor  of  Link  when  creating  p.  Since  la  can  be  accessed 
through  p  from  now  on,  we  do  not  need  to  mention  la  in  the  following  object  proposition  sets. 
In  this  respect,  our  system  is  an  affine  one  (as  opposed  to  a  linear  one),  because  we  can  drop  a 
resource  if  we  do  not  need  it  any  more. 

When  creating  the  object  q,  we  need  to  pass  in  a  fraction  to  p.  We  obtain  it  by  splitting  the 
current  fraction  of  1  to  p  into  two  fractions.  Before  calling  method  addModuloll  on  r,  we  also 
have  to  split  the  fraction  to  r  so  that  a  fraction  can  be  passed  to  the  method.  The  splitting  of 
fractions  is  similar  when  we  call  addModuloll  on  q. 

The  specification  in  separation  logic  is  more  cumbersome  and  unable  to  hide  shared  data.  To 
express  the  fact  that  all  values  in  a  segment  of  linked  elements  are  in  the  interval  [711,02],  we  need 
to  define  the  following  predicate  : 

Listseg{r,p,  rti,  712)  =  {r  =  p)  V  {r  ^  {i,  s)-k 
Listseg[s,p,  tii,  712)  A  7ii  <  i  <  712). 

This  predicate  states  that  either  the  segment  is  null,  or  the  val  field  of  r  points  to  i  and  the  Tiext 
field  points  to  s,  such  that  tii  <  i  <  712,  and  the  elements  on  the  segment  from  s  to  p  are  in  the 
interval  [rii,  712].  The  verification  of  the  same  code  in  separation  logic  is  shown  below: 

”{} 

Link  la  =  new  Link  (3,  null); 

{Listseg{la,  tiuU,  0, 10)} 

Link  p  =  new  Link (6,  la); 

{Listseg[p,  null,  0, 10)} 

Link  q  =  new  Link(l,  p) ; 

{Listseg{q,p,  0, 10)  *  Listseg{p,  null,  0, 10)} 

Link  r  =  new  Link  (8,  p) ; 

{Listseg{q,  p,  0, 10)  *  Listseg{r,  p,  0, 10) 

■k  Listseg{p,  null,  0, 10)} 

{Listseg{q,p,  0, 10)  ★  Listsegir,  null,  0, 10)} 
r . addModuloll  (  9) ; 

{Listseg{q,p,  0, 10)  k  Listsegir,  null,  0, 10)} 

*****missing  step***** 

{Listsegiq,  null,  0, 10)  k  Listseg{r,p,  0, 10)} 
q . addModulel 1  ( 7 ) ; 

{Listsegiq,  tiuU,  0, 10)  k  Listsegir,  p,  0, 10)} 


In  separation  logic,  the  natural  pre-  and  post-conditions  of  the  method  addModuloll  are 
Listsegithis,  null,  0, 10),  i.e.,  the  method  takes  in  a  list  of  elements  in  [0, 10]  and  returns  a  list 
in  the  same  range. 
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Thus,  before  calling  addModulol  1  on  r,  we  have  to  combine 

Listseg{r,  p,  0, 10)  Listseg{p,  null,  0, 10) 

into  Listseg{r,  null,  0, 10).  We  observe  the  following  problem:  in  order  to  call  addModulol  1 
on  q,  we  have  to  take  out  Listseg{p,  null,  0, 10)  and  combine  it  with  Listseg{q,p,  0, 10),  to  obtain 
Listseg{q,  null,  0, 10).  But  the  specification  of  the  method  does  not  allow  it,  hence  the  missing 
step  in  the  verification  above.  The  specification  of  addModulol  1  has  to  be  modified  instead,  by 
mentioning  that  there  exists  some  sublist  Listseg{p,  null,  0, 10)  that  we  pass  in  and  which  gets 
passed  back  out  again.  The  modification  is  unnatural:  the  specification  of  addModulol  1  should 
not  care  that  it  receives  a  list  made  of  two  separate  sublists,  it  should  only  care  that  it  receives  a  list 
in  range  [0, 10]. 

This  situation  is  very  problematic  because  the  specification  of  addModulol  1  involving  sub¬ 
lists  becomes  awkward.  We  can  imagine  an  even  more  complicated  example,  where  there  are  three 
sublists  that  we  need  to  pass  in  and  out  of  addModulol  1.  It  is  impossible  to  know,  at  the  time 
when  we  write  the  specification  of  a  method,  on  what  kind  of  shared  data  that  method  will  be  used. 
Separation  logic  approaches  will  thus  have  a  difficult  time  trying  to  verify  this  kind  of  code,  while 
object  propositions  allow  us  to  call  methods  on  both  lists,  without  requiring  the  combination  of 
two  predicates. 

4.1  Example:  Cells  in  a  spreadsheet 

I  consider  the  example  of  a  spreadsheet,  as  described  in  [17].  In  my  spreadsheet  each  cell  contains 
an  add  formula  that  adds  two  integer  inputs.  Each  cell  may  refer  to  other  two  cells.  The  general 
case  would  be  for  each  cell  to  have  a  dependency  list  of  cells,  but  since  my  grammar  does  not 
support  arrays  yet,  I  am  not  considering  that  case.  Whenever  the  user  changes  a  cell,  each  of  the 
two  cells  which  transitively  depend  upon  it  must  be  updated. 

A  visual  representation  of  this  example  is  presented  in  Figure  3.  In  separation  logic,  the  spec¬ 
ification  of  any  method  has  to  describe  the  entire  footprint  of  the  method,  i.e.,  all  heap  locations 
that  are  being  touched  through  reading  or  writing  in  the  body  of  the  method.  That  is,  the  shared 
cells  a3  and  a6  have  to  be  specified  in  the  specification  of  all  methods  that  modify  the  cells  al  and 
a2. 

In  Figure  4, 1  present  the  code  implementing  a  cell  in  a  spreadsheet. 

The  specification  in  separation  logic  is  unable  to  hide  shared  data.  To  express  the  fact  that  all 
cells  are  in  a  consistent  state  where  the  dependencies  are  respected  and  the  sum  of  the  inputs  is 
equal  to  the  output  for  each  cell,  I  define  the  following  predicate  : 

SepOK{cell)  =  {cell. ini  — >■  xl)  ★  {cell.in2  — x2)  -k  [cell. out  o)  -k  [cell.depl  — )•  dl)  k 
[cell.dep2  — >  d2)k[xl  +  x2  =  o)*(S'epO/f (dl.ce)  Adl.ce. “in  +  mpuf’  — >  o)k[SepOK[d2.ce) /\ 
{[d2.ce.inl  —>  o  A  d2.input  =  1)  V  {d2.ce.in2  -A  o  A  d2.input  =  2))). 

This  predieate  states  that  the  sum  of  the  two  inputs  of  cell  is  equal  to  the  output,  and  that  the 
predicate  SepOK  is  verified  by  all  the  cells  that  directly  depend  on  the  output  of  the  current  cell. 
Additionally,  the  predicate  SepOK  also  checks  that  the  corresponding  input  for  each  of  the  two 
dependency  cells  is  equal  to  the  output  of  the  eurrent  eell.  This  predieate  only  works  in  the  case 
when  the  cells  form  a  directed  acyelic  graph  (DAG).  The  predieate  SepOK  causes  problems  when 
there  is  a  diamond  structure  (not  shown  in  Figure  3)  or  if  one  wants  to  assert  the  predicate  about 
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Figure  3:  Add  cells  in  spreadsheet 
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class  Dependency  { 

Cell  ce; 
int  input; 

} 

class  Cell  { 

int  ini,  in2,  out; 

Dependency  depl,  dep2 ; 

void  setInputDep ( int  newinput)  { 
if  (depl ! =null)  { 

if  (depl. input  ==  1)  depl . ce . setlnputl (newinput) ; 
else  depl . ce . setlnput2 (newinput)  ; 

} 

if  (dep2 ! =null)  { 

if  (dep2. input  ==  1)  dep2 . ce . setlnputl (newinput) ; 
else  dep2 . ce . setlnput2 (newinput)  ; 

} 

} 

void  setlnputl (int  x)  { 
this. ini  =  x; 

this. out  =  this. ini  +  this.in2; 
this . setInputDep (out )  ; 

} 


void  setlnput2 ( int  x)  { 
this.in2  =  x; 

this. out  =  this. ini  +  this.in2; 
this . setInputDep (out ) ; 

} 


} 


Figure  4:  Cell  class 
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Figure  5:  Cells  in  a  eycle 


two  separate  nodes  whose  subtrees  overlap  due  to  a  DAG  structure  (e.g.  al  and  a2  in  Figure  3). 
If  the  dependencies  between  the  cells  form  a  cycle,  as  in  Figure  5,  the  predicate  SepOK  cannot 
possibly  hold. 

Additionally  we  need  another  predicate  to  express  simple  properties  about  the  cells: 

Basic{cell)  =  3x1,  x2,  o,  d. {cell. ini  xl)  -k  {cell.in2  — )■  x2)  ★  {cell. out  o)-k  {cell.dep 

d). 

Below  I  show  a  fragment  of  client  code  and  its  verification  using  separation  logic. 

{Basic{a2)  *  Basic{ab)  ★  SepOK{a\)} 
al . setlnputl  (10) ; 

{Basic{a2)  *  Basic{a5)  *  SepOK{al)} 

miSSiUg  step  *****=*:*  *!(!} 

{Basic{a4:)  *  Basic{al)  *  SepOK{a2)} 
a 2 . setlnputl  (20) ; 


In  the  specification  above, 

SepOK{al)  =  al.inl  ^  xl  *  al.m2  x2-k  al.out  — >-o^xl  +  x2  =  o* 

{SepOK{aA)  A  a4.ml  =  o)  ★  {SepOK {all)  A  al.inl  =  o) 

and 

SepOK  (a2)  =  a2.ml  zl-k  a2.in2  — >■  t2  ★  a2.out  -^p-kzl  +  z2=p-k 
{SepOK {al)  A  al.in2  =  p)  ★  {SepOK {ab)  A  ab.inl  =  p) 

In  separation  logic,  the  natural  pre-  and  post-conditions  of  the  method  setlnputl  are  SepOK  {this), 
i.e.,  the  method  takes  in  a  cell  that  is  in  a  consistent  state  in  the  spreadsheet  and  returns  a  cell  with 
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the  input  changed,  but  that  is  still  in  a  consistent  state  in  the  spreadsheet.  Note  that  the  pre¬ 
condition  does  not  need  to  be  of  the  form  SepOK{this,  carrier)  where  carrier  is  all  the  cells 
involved  as  in  Jacobs  et  al.’s  work  [15].  This  is  because  SepOK  is  a  recursive  abstract  predicate 
that  states  in  its  definition  properties  about  the  cells  that  depend  on  the  current  this  cell  and  thus  we 
do  not  need  to  explicitly  carry  around  all  the  cells  involved.  The  natural  specification  of  setlnputl 
would  be  SepOKithis)  ^  SepOK{this). 

Thus,  before  calling  setlnputl  on  a2,  we  have  to  combine  SepOK{a3)  ★  SepOK(a5) 
into  SepOK{a2).  We  observe  the  following  problem:  in  order  to  call  setlnputl  on  a2,  we 
have  to  take  out  SepOK{a3)  and  combine  it  with  SepOK {a5),  to  obtain  SepOK{a2).  But  the 
specification  of  the  method  does  not  allow  it,  hence  the  missing  step  in  the  verification  above.  The 
specification  of  set  Input  1  has  to  be  modified  instead,  by  mentioning  that  there  exists  some  cell 
a3  that  satisfies  SepOK{a3)  that  we  pass  in  and  which  gets  passed  back  out  again.  Thus,  if  we 
want  to  call  setlnputl  on  a2,  the  specification  of  setlnputl  would  have  to  know  about  the 
specific  cell  a3,  which  is  not  possible. 

The  specification  of  setlnputl  would  become 

Va,  /3,  X  .  {SepOK (this)  A  SepOK (this)  =  a  *  SepOK (x)  ★  /3) 

{SepOK {this)  A  SepOK {this)  =  a -k  SepOK{x) -k /3). 

The  modification  is  unnatural:  the  specification  of  setlnputl  should  not  care  about  which 
are  the  dependencies  of  the  current  cell,  it  should  only  care  that  it  modified  the  current  cell. 

This  situation  is  very  problematic  because  the  specification  of  setlnputl  involving  shared 
cells  becomes  awkward.  One  can  imagine  an  even  more  complicated  example,  where  there  are 
multiple  shared  cells  that  need  to  be  passed  in  and  out  of  different  calls  to  setlnputl.  It  is 
impossible  to  know,  at  the  time  when  we  write  the  specification  of  a  method,  on  what  kind  of 
shared  data  that  method  will  be  used. 

In  Figure  6,  we  present  the  Java  class  from  Figure  4  augmented  with  predicates  and  object 
propositions,  which  are  useful  for  reasoning  about  the  correctness  of  client  code  and  about  whether 
the  implementation  of  a  method  respects  its  specification.  Since  they  contain  fractional  permis¬ 
sions  which  represent  resources  that  have  to  be  consumed  upon  usage,  the  object  propositions  are 
consumed  upon  usage  and  their  duplication  is  forbidden.  Therefore,  we  use  linear  logic  [12]  to 
write  the  specifications.  Pre-  and  post-conditions  are  separated  with  a  linear  implication  ^  and 
use  multiplicative  conjunction  (®),  additive  disjunction  (0)  and  existential/universal  quantifiers 
(where  there  is  a  need  to  quantify  over  the  parameters  of  the  predicates). 

Newly  created  objects  have  a  fractional  permission  of  1,  and  their  state  can  be  manipulated 
to  satisfy  different  predicates  defined  in  the  class.  A  fractional  permission  of  1  can  be  split  into 
two  fractional  permissions  which  are  less  than  1,  see  Figure  8.  The  programmer  can  specify  an 
invariant  that  the  object  will  always  satisfy  in  future  execution.  Different  references  pointing  to  the 
same  object,  will  always  be  able  to  rely  on  that  invariant  when  calling  methods  on  the  object. 

A  critical  part  of  our  work  is  allowing  clients  to  depend  on  a  property  of  a  shared  object.  Other 
methodologies  such  as  Boogie  [1]  allow  a  client  to  depend  only  on  properties  of  objects  that  it 
owns.  Our  verification  technique  also  allows  a  client  to  depend  on  properties  of  objects  that  it 
doesn’t  (exclusively)  own. 

To  gain  read  or  write  access  to  the  fields  of  an  object,  we  have  to  unpack  it  [7].  After  a 
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class  Dependency  { 

Cell  ce; 
int  Input; 

predicate  OKdep{int  o)  =  3c,  k,  i.this.ce  — >  c  ®  this.input  — >• 

((i  =  l0c@^  lnl{o)0c@k  0K())  ©  (i  =  2  (g)  c@|  In2{o)  ®  c@k  0K{))) 

} 

class  Cell  { 

int  ini,  in2,  out; 

Dependency  depl,  dep2; 

predicate  Inl{int  xl)  =  this.inl  — >  xl 

predicate  In2{int  x2)  =  this.in2  — )>  x2 

predicate  OKQ  =  3x1,  a;2,  o,  dl,  c?2d/iis@|  Inl{xl)  ®  this@\  In2{x2)<S) 
xl  +  x2  =  o  0  this. out  ^00  this. depl  — >  rfl  0  this.dep2  — >  d20 
(il@l  OKdep{o)  0  (i2@l  OKdep{o) 

void  setInputDep (int  1,  int  newinput)  { 
if  (depl ! =null)  { 

if  (depl. input  ==  1)  depl . ce . setlnputl (newinput) ; 
else  depl . ce . setlnput2 (newinput)  ; 

} 

if  (dep2 ! =null)  { 

if  (dep2. input  ==  1)  dep2 . ce . setlnputl (newinput) ; 
else  dep2 . ce . setlnput2 (newinput)  ; 

} 

} 

void  setlnputl  (int  x) 
yk.{this@k  OK{)  this@k  0K{)) 

{  this . ini  =  x; 

this. out  =  this.inl  +  this.in2; 
this . setInputDep (out) ; 

} 

void  setlnput2  (int  x) 
yk.{this@k  OK{)  — o  this@k  OK()) 

{  this.in2  =  x; 

this. out  =  this.inl  +  this.in2; 
this . setInputDep (out) ; 

} 


} 


Figure  6:  Cell  class  and  OK  predicate 


method  finishes  working  with  the  fields  of  a  shared  object  (an  object  for  which  we  have  a  fractional 
permission,  with  a  fraction  less  than  1),  our  proof  rules  in  Section  6  require  us  to  ensure  that  the 
same  predicate  as  before  the  unpacking  holds  of  that  shared  object.  If  the  same  predicate  holds,  we 
are  allowed  to  pack  back  the  shared  object  to  that  predicate.  Since  for  an  object  with  a  fractional 
permission  of  1  there  is  no  risk  of  interferences,  we  don’t  require  packing  to  the  same  predicate 
for  this  kind  of  objects.  We  avoid  inconsistencies  by  allowing  multiple  object  propositions  to  be 
unpacked  at  the  same  time  only  if  the  objects  are  not  aliased,  or  if  the  unpacked  propositions  cover 
disjoint  fields  of  a  single  object. 

Packing/unpacking  [7]  is  a  very  important  mechanism  in  our  system.  The  benefits  of  this 
mechanism  are  the  following: 

•  it  achieves  information  hiding  (e.g.  like  abstract  predicates) 

•  it  describes  the  valid  states  of  the  system  (similar  to  visible  states  in  invariant-based  ap¬ 
proaches) 

•  it  is  a  way  to  store  resources  in  the  heap.  When  a  field  key  is  put  (packed)  into  a  predicate,  it 
disappears  and  cannot  be  accessed  again  until  it  is  unpacked 

•  it  allows  us  to  characterize  the  correctness  of  the  system  in  a  simple  way  when  everything  is 
packed 

Another  central  idea  of  our  system  is  sharing  using  fractions  less  than  1.  The  insights  about 
sharing  are  the  following: 

•  with  a  fractional  permission  of  1,  no  sharing  is  permitted.  There  is  only  one  of  each  ab¬ 
stract  predicate  asserted  for  each  object  at  run  time,  and  the  asserted  abstract  predicates  have 
disjoint  fields. 

•  fractional  permissions  less  than  1  enable  sharing  of  particular  abstract  predicates,  but  only 
one  instance  of  a  particular  abstract  predicate  P  on  a  particular  object  o  can  be  unpacked  at 
once.  This  ensures  that  field  permissions  cannot  be  duplicated  via  shared  permissions. 

An  important  aspect  of  our  system  is  the  ability  to  allow  predicates  to  depend  on  each  other. 
Intuitively,  this  allows  “chopping  up"  an  invariant  into  its  modular  constituent  parts. 

Like  other  previous  systems,  our  system  uses  abstraction,  which  allows  clients  to  treat  method 
pre/post-conditions  opaquely. 

The  predicate  OK( )  in  Figure  6  ensures  that  all  the  cells  in  the  spreadsheet  are  in  a  consistent 
state,  where  the  sum  of  their  inputs  is  equal  to  their  output.  Since  we  only  use  a  fractional  permis¬ 
sions  fcl,  fc2  <  1  for  the  dependency  cells,  it  is  possible  for  multiple  predicates  OK{)  to  talk  about 
the  same  cell  without  exposing  the  sharing.  More  specifically,  using  object  propositions  we  only 
need  to  know  al@A:  OKQ  before  calling  al.setlnputl{10).  Before  calling  a2.  set  I  nputl  (20)  we 
only  need  to  know  a2@k  OK () .  Since  inside  the  recursive  predicate  OK ()  there  are  fractional  per¬ 
missions  less  than  1  that  refer  to  the  dependency  cells,  we  are  allowed  to  share  the  cell  a3  (which 
can  depend  on  multiple  cells).  Thus,  using  object  propositions  we  are  not  explicitly  revealing  the 
shared  cells  in  the  structure  of  the  spreadsheet. 
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Prog  ::= 

CIDecI  e 

CIDecI  :;= 

class  C  {  FIdDecI  PredDecI  MthDecI 

FIdDecI  ::= 

T/  _ 

PredDecI  ::= 

predicate  2  (T  X)  =  R 

MthDecI  ::= 

T  m  (T  X)  MthSpec  {  e;  return  e  } 

MthSpec 

R  ^  R 

R  ::= 

P  1  R  (g)  R  1  R  ©  R  1 

3z.P  1  Vz.R  1  r.f^x  1  t  binop  t 

P  ::= 

r@k2(t)  1  unpacked  (r@k  2  (t)  ) 

k  ::= 

^  (where  ni,  n2  G  N  and  0  <  ni  <  n2) 

e  ::= 

t  1  r.f  1  r.f  =  t  1  r.m{l)  1  newC  (t) 

if  (t)  {  e  }  else  {  e  }  1 

let  X  =  e  in  e  1 

t  binop  t  1  t  &&  t  1  t  t  1  !  t  1 

pack  r@k  2  (t)  in  e  1 

unpack  r@k  Q  (t)  in  e 

t  :;= 

X  1  n  1  null  1  true  1  false 

X  ::= 

r  1  i 

binop  ::= 

+ 

1 

II 

II 

lA 

A 

IV 

V 

T  ::= 

C  1  int  1  boolean 

Figure  7:  Grammar  of  language  and  specification 


5  Grammar 

The  programming  language  that  we  are  using  is  inspired  by  Featherweight  Java  [13],  extended  to 
include  object  propositions.  We  retained  only  Java  concepts  relevant  to  the  core  technical  con¬ 
tribution  of  this  paper,  omiting  features  such  as  inheritance,  casting  or  dynamic  dispatch  that  are 
important  but  are  handled  by  orthogonal  techniques. 

Below  we  show  the  syntax  of  our  simple  class-based  object-oriented  language.  In  addition  to 
the  usual  constructs,  each  class  can  define  one  or  more  abstract  predicates  Q  in  terms  of  concrete 
formulas  R.  Each  method  comes  with  pre  and  post-condition  formulas.  Formulas  include  object 
propositions  P,  terms,  primitive  binary  predicates,  conjunction,  disjunction,  keys,  and  quantifi¬ 
cation.  We  distinguish  effectful  expressions  from  simple  terms,  and  assume  the  program  is  in 
let-normal  form.  The  pack  and  unpack  expression  forms  are  markers  for  when  packing  and  un¬ 
packing  occurs  in  the  proof  system.  References  o  and  indirect  references  I  do  not  appear  in  source 
programs  but  are  used  in  the  dynamic  semantics,  defined  later.  In  the  grammar,  r  represents  a 
reference  to  an  object  and  i  represents  a  reference  to  an  integer. 

In  our  system,  we  will  assume  that  all  the  formulas  R  are  in  disjunctive  normal  form.  A 
formula  R  of  our  system  is  in  disjunctive  normal  form  if  and  only  if  it  is  an  additive  disjunction  of 
one  or  more  multiplicative  conjunctions  of  one  or  more  of  the  predicates  P  ,  binop  ^2  ,  ?’•/—> 
X  ,  3z.P  ,  \lz.P. 
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k  e  (0,1] 

r@k  Q{t)  h  r(a|  Q{i)  0  rOf  Q{t) 


(Split) 


Figure  8:  Rule  for  splitting  fractions 

5.1  Permission  Splitting 

In  order  to  allow  objects  to  be  aliased,  we  must  split  a  fraction  of  1  into  multiple  fractions  less  than 
1  [5].  The  fraction  splitting  rule  is  defined  in  Figure  8.  An  invariant  of  the  rules  is  that  a  fraction  of 
1  is  never  duplicated.  We  also  allow  the  inverse  of  splitting  permissions:  joining,  where  we  define 
the  rules  in  Figure  9. 


6  Proof  Rules 

This  section  describes  the  proof  rules  that  can  be  used  to  verify  correctness  properties  of  code. 
The  judgement  to  check  an  expression  e  is  of  the  form  F;  If  h  e  :  3x.T;  R.  This  is  read  “in 
valid  context  F  and  linear  context  FI,  an  expression  e  executed  has  type  T  with  postcondition 
formula  i?”.This  judgement  is  within  a  receiver  class  C,  which  is  mentioned  when  necessary  in 
the  assumptions  of  the  rules.  By  writing  3x,  we  bind  the  variable  x  to  the  result  of  the  expression 
e  in  the  postcondition.  F  gives  the  types  of  variables  and  references,  while  If  is  a  pre-condition  in 
disjunctive  normal  form.  The  linear  context  IT  should  be  just  as  general  as  R. 
type  context  F  ::=  ■  |  F,x  :  T 

linear  context  If  0Li  n. 

FIj  ;:=  •  I  Fli  0)  P  I  Fli  ®  binop  ^2  | 

Hi®  r.f  ^  X  \  Rz.P  I  V^.P 

The  static  proof  rules  also  contain  the  following  judgements:  FI-r:C,  F;ni-i?  and 
F;  Ft  h  r.T ;  R.  The  judgement  F  h  r  :  (7  means  that  in  valid  type  context  F,  the  reference  r  has 
type  C.  The  judgement  F;  FI  h  i?  means  that  from  valid  type  context  F  and  linear  context  FI  we  can 
deduce  that  object  proposition  R  holds.  The  judgement  F;  FI  h  r.T ;  R  means  that  from  valid  type 
context  F  and  linear  context  FI  we  can  deduce  that  reference  r  has  type  T  and  object  proposition 
R  is  true  about  r.  The  0  linear  logic  operator  is  symmetric.  Thus  in  the  rules  for  adding  fractions, 
we  can  have  a  rule  symmetric  to  (Add2)  that  adds  the  fraction  of  a  packed  object  propositions  to 
the  fraction  of  an  unpacked  object  proposition. 

Before  presenting  the  detailed  rules,  I  provide  the  intuition  for  why  my  system  is  sound  (the 
formal  soundness  theorem  is  given  below  in  Section9.1).  The  first  invariant  enforced  by  my  system 
is  that  there  will  never  be  two  conflicting  object  propositions  to  the  same  object.  The  fraction 
splitting  rule  can  give  rise  to  only  one  of  two  situations,  for  a  particular  object:  there  exists  a 
reference  to  the  object  with  a  fraction  of  1,  or  all  the  references  to  this  object  have  fractions  less 
than  1 .  For  the  first  case,  sound  reasoning  is  easy  because  aliasing  is  prohibited. 

The  second  case,  concerning  fractional  permissions  less  than  1,  follows  an  inductive  argument 
in  nature.  The  argument  is  based  on  the  property  that  the  invariant  of  a  shared  object  (one  can 
think  of  an  object  with  a  fraction  less  than  1  as  being  shared)  always  holds  whenever  that  object  is 


16 


e  G  (0, 1)  A:  G  (0, 1]  e  <  k 
r@e  Q{ti)  0  r@(A:  —  e)  Q{ti)  h  r@k  Q{ti) 


(AddI) 


e  G  (0, 1)  A:  G  (0, 1]  e  <k 

unpacked{r@e  Q{ti))  0  r@{k  —  e)  Q{ti)  h 
unpacked{r@k  Q{ti)) 


(Add2) 


Figure  9:  Rules  for  adding  fractions 


packed.  The  base  case  in  the  induction  occurs  when  an  object  with  a  fraction  of  1,  whose  invariant 
holds,  first  becomes  shared.  In  order  to  access  the  fields  of  an  object,  we  must  first  unpack  the 
corresponding  predicate;  by  induction,  we  can  assume  its  invariant  holds  as  long  as  the  object  is 
packed.  But  we  know  the  object  is  packed  immediately  before  the  unpack  operation,  because  the 
rules  of  my  system  ensure  that  a  given  predicate  over  a  particular  object  can  only  be  unpacked 
once;  therefore,  we  know  the  object’s  invariant  holds.  Assignments  to  the  object’s  fields  may  later 
violate  the  invariant,  but  in  order  to  pack  the  object  back  up  we  must  restore  its  invariant.  For 
a  shared  object,  packing  must  restore  the  same  predicate  the  object  had  when  it  was  unpacked; 
thus  the  invariant  of  an  object  never  changes  once  that  object  is  shared,  avoiding  inconsistencies 
between  aliases  to  the  object.  (Note  that  if  at  a  later  time  we  add  the  fractions  corresponding  to  that 
object  and  get  a  fraction  of  1,  we  will  be  able  to  change  the  predicates  that  hold  of  that  object.  But 
as  long  as  the  object  is  shared,  the  invariant  of  that  object  must  hold.)  Although  theoretically  an 
object  may  have  several  different  invariants,  in  all  my  examples  in  my  thesis  proposal  each  object 
has  only  one  invariant.  In  future  work  I  would  like  to  support  multiple  invariants  for  the  same 
object,  but  this  thesis  does  not  deal  with  this  case. 

This  completes  the  inductive  case  for  soundness  of  shared  objects.  The  induction  is  done  on 
the  steps  when  a  predicate  is  packed  or  unpacked.  All  of  the  predicates  we  might  infer  will  thus  be 
sound  because  we  will  never  assume  anything  more  about  that  object  than  the  predicate  invariant, 
which  should  hold  according  to  the  above  argument. 

In  the  following  paragraphs,  we  describe  the  proof  rules  while  inlining  the  rules  in  the  text.  In 
the  rules  below  we  assume  that  there  is  a  class  C  that  is  the  same  for  all  the  rules. 

The  rule  Term  below  formalizes  the  standard  logical  judgement  for  existential  introduction. 
The  notation  \e' /x]e  substitutes  e'  for  occurrences  of  x  in  e.  The  FIELD  rule  checks  field  accesses 
analogously. 
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rht:T  r;Uh[t/x]R 
F;  n  h  t  :  3x.T ;  R 


Term 


r  h  r  :  C  r.fi  :  T  is  a  field  of  C 
Uhr.fi^n  [ri/x]R 


r;n  h  r.fi  :  3x.T]R 


Field 


New  checks  object  construction.  We  get  a  key  for  each  field  and  the  remaining  linear  context 
Hi.  The  context  Hi  contains  the  object  propositions  taken  from  If  from  which  we  consumed  the 
keys. 

fields{C)  =  TJ  r  h  TTt 

- - = — z - New 

F;  n  h  new  C{t)  :  3z.C]  z.f  ^  t  0  Hi 

If  introduces  disjunctive  types  in  the  system  and  checks  ^/-expressions.  A  corresponding  ©  rule 
eliminates  disjunctions  in  the  pre-condition  by  verifying  that  an  expression  checks  under  either 
disjunct. 

F;  (n  0  t  =  true)  h  e\  :  3x.T]  Ri 
F  h  t  :  bool  F;  (If  0  t  =  false)  h  62  :  3x.T;  R2 
F;F[h  lf(t)  {ei}else{e2}  :  3x.T]Ri  ©  R2 

Let  checks  a  let  binding,  extracting  existentially  bound  variables  and  putting  them  into  the 
context  (a  limitation  of  my  current  system  is  that  universal  quantification  is  supported  only  in 
method  specifications). 


F;  n  h  ei  :  3x.Ti ;  iii  0  112 
(F,  a;  :  Ti);  (i?i  0  112)  F  62  :  3w.T2;  R2 
F;  n  F  let  x  =  ei  in  62  :  3w.T2]  R2 


Let 


F;  Hi  F  e  :  3x.T ;Ri  F;  112  F  e  :  3x.T ;  R2 

F;(ni©n2)Fe:3x.r;i?i©i?2  ® 

The  Call  rule  simply  states  what  is  the  object  proposition  that  holds  about  the  result  of  the 
method  being  called.  This  rule  first  identifies  the  specification  of  the  method  (using  the  helper 
judgement  Mtype)  and  then  goes  on  to  state  the  object  proposition  holding  for  the  result.  The  F 
notation  in  the  fourth  premise  of  the  CALL  rule  represents  entailment  in  linear  logic. 

The  reader  might  see  that  there  are  some  concerns  about  the  modularity  of  the  CALL  rule: 
Hi  shouldn’t  contain  unpacked  predicates.  Indeed,  it  is  important  that  the  CALL  rule  tracks  all 
shared  predicates  that  are  unpacked.  It  does  not  track  predicates  that  are  packed,  nor  unpacked 
predicates  that  have  a  fractional  permission  of  1.  The  normal  situation  is  that  all  shared  predicates 
are  packed,  and  any  method  can  be  called  in  this  situation.  In  the  intended  mode  of  use,  we  only 
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make  calls  with  a  shared  unpacked  predicate  when  traversing  a  data  structure  hand-over-hand  as 
in  the  Composite  pattern,  and  we  claim  that  modularity  problems  are  minimized  in  this  situation. 
This  does  represent  a  limitation  in  our  system,  however,  it  is  one  that  goes  hand  in  hand  with  the 
advantage  of  supporting  shared  predicates. 


r  h  ro  :  Co  r  h  ti  :  T 
F;  n  h  [rQ/this\\ti/x\Ri  ®  Hi 
mtype{m,  Co)  =  Vx  :  T3result.Tr;  R'l  R 
Ri  h  i?; 

Hi  cannot  contain  unpacked  predicates 
F;  n  h  ro.m(ti)  :  3  result.Tr]  [ro/this\[ti/x\R  ®  Hi 


Call 


class  C{...M G  CL 

Tr  m{Tx)Ri  — o  R  {eT;  return  62}  G  M 

- ; - - - ^ -  MTYPE 

mtype{m,  C)  =  Vx  :  T.3result.Tr;  Ri  —o  R 

The  rule  Assign  assigns  an  object  t  to  a  held  /*  and  returns  the  old  held  value  as  an  existential 
X.  For  this  rule  to  work,  the  current  object  this  has  to  be  unpacked,  thus  giving  us  permission  to 
modify  the  helds. 


F;  If  h  :  T*;  ti@ko  Qo(to)  <S>  Hi 
r;nihri.fr.R;r'@k'  Q'(F)  ®  Ha 
112  F  ri.fi  ^  r'  ®  113 

- ^ Assign 

F;  n  I-  ri./j  =  ti  :  Bx.Tp,  x@k'  Q  {t')  ®  ti@ko  Qo{to) 

O  ri.fi  C  ®  Fla 

The  rules  for  packing  and  unpacking  are  PackI,  Pack2,  Unpack  1  and  Unpack2.  As  men¬ 
tioned  before,  when  we  pack  an  object  to  a  predicate  with  a  fraction  less  than  1,  we  have  to  pack  it 
to  the  same  predicate  that  was  true  before  the  object  was  unpacked.  The  restriction  is  not  necessary 
for  a  predicate  with  a  fraction  of  1 :  objects  that  are  packed  to  this  kind  of  predicate  can  be  packed 
to  a  different  predicate  than  the  one  that  was  true  for  them  before  unpacking.  For  example,  in 
Figure  6,  the  method  setlnputl  has  as  pre-condition  the  object  proposition  this@k  OK{).  Since 
the  fraction  k  is  universally  quantified  and  can  be  less  than  1,  the  this  object  in  the  post-condition 
must  be  sure  to  satisfy  the  predicate  OK{)  (which  happens  to  also  be  an  invariant  in  this  example). 
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T;  n  h  r  :  C;  [t2/x]R2  ®  IIi 
predicate  Q2{Tx)  =  R2  ^  C 

T;  (El  (g)  r@l  <52(^2))  1“  e  :  3x.T]R 

- Pac  k  1 

F;  n  h  pack  r@l  (32(^2)  in  e  :  3x.T;  R 


F;  n  h  r  :  C;  [E/xJi?!  (g)  unpacked (r@/c  Q(ti))  (gi  Ei 
predicate  Q(Tx)  =  Ri  G  C  0  <  k  <  1 
F;  (El  g)  r@k  Q{h))  h  e  :  Bx.T;  R 

F;  E  h  pack  r@k  Q{ti)  in  e  :  3x.T]  R 


As  mentioned  earlier,  we  allow  unpacking  of  multiple  predicates,  as  long  as  the  objects  don’t 
alias.  We  also  allow  unpacking  of  multiple  predicates  of  the  same  object,  because  we  have  a  single 
linear  write  permission  to  each  field.  There  can’t  be  any  two  packed  predicates  containing  write 
permissions  to  the  same  field. 


F;  E  F  r  :  C*;  r@l  Q{ti)  (g)  Ei 
predicate  Q{Tx)  =  Ri  G  C 

F;  (El  (g)  [ti/x]Ri)  h  e  :  zlx.T;  R 

- Unpack.  1 

F;  E  h  unpack  r@l  Q{ti)  in  e  :  3x.T;  R 


F;E  F  r  :  C;  r@k  g(ti)  g)  Ei 
predicate  Q{Tx)  =  Ri  (z  C  0<fc<l 
F;  (El  g  [E"/x]i?i  g  unpacked(r@A:  Q(h))  F  e  :  3x.T;  R 
:  (  unpacked{r'@k'  Q{t))  e  E  =t  E  F  r  /  r') 

F;  E  F  unpack  r@k  Q{ti)  in  e  :  3x.r;  R 


Unpack2 


We  have  also  developed  rules  for  the  dynamic  semantics,  that  are  used  in  proving  the  soundness  of 
our  system.  Section  9  describes  in  detail  the  dynamic  semantics  rules  and  the  soundness  theorem. 
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Simulator  for  queues  of  jobs  Modification  of  the  simulator 


Figure  10: 

7  Specification  for  Modularity 

To  illustrate  the  modularity  issues,  we  present  here  a  more  realistic  example  than  the  queue  exam¬ 
ple  from  Section  4.  In  Figure  10  we  depict  a  simulator  for  two  queues  of  jobs,  containing  large 
jobs  (sizolO)  and  small  jobs  (size<ll).  The  example  is  relevant  in  queueing  theory,  where  an 
optimal  scheduling  policy  might  separate  the  jobs  in  two  queues,  according  to  some  criteria.  The 
role  of  the  control  is  to  make  each  producer/consumer  periodically  take  a  step  in  the  simulation. 
We  have  modeled  two  FIFO  queues,  two  producers,  two  consumers  and  a  control  object.  Each 
producer  needs  a  pointer  to  the  end  of  each  queue,  for  adding  a  new  job,  and  a  pointer  to  the  start 
of  each  queue,  for  initializing  the  start  of  the  queue  in  case  it  becomes  empty.  Each  consumer  has 
a  pointer  to  the  start  of  one  queue  because  it  consumes  the  element  that  was  introduced  first  in  that 
queue.  The  control  has  a  pointer  to  each  producer  and  to  each  consumer.  The  queues  are  shared 
by  the  producers  and  consumers,  thus  giving  rise  to  a  number  of  aliased  objects  with  fractions  less 
than  1. 

Now,  let’s  say  the  system  has  to  be  modified,  by  introducing  two  queues  for  the  small  jobs 
and  two  queues  for  the  large  jobs,  see  right  image  of  Eigure  10.  Ideally,  the  specification  of  the 
control  object  should  not  change,  since  the  consumers  and  the  producers  have  the  same  behavior 
as  before:  each  producer  produces  both  large  and  small  jobs  and  each  consumer  accesses  only  one 
kind  of  job.  We  will  show  in  the  following  sections  that  our  methodology  does  not  modify  the 
specification  of  the  control  object,  thus  allowing  us  to  make  changes  locally  without  influencing 
other  code,  while  (first-order)  separation  logic  approaches  [9]  will  modify  the  specification  of  the 
controller. 

The  code  in  Eigures  11,  12  and  13  represents  the  initial  running  example  from  Eigure  10.  The 
predicates  and  the  specifications  of  each  class  explain  how  the  objects  and  methods  should  be  used 
and  what  is  their  expected  behavior.  For  example,  the  Producer  object  has  access  to  the  two  queues. 
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public  class  Consumer 
Link  startJobs; 


public  class  Producer  { 

Link  startSmallJobs , 
startLarge Jobs ; 

Link  endSmallJobs, 
endLarge Jobs ; 

predicate  BothInRange ( )  = 
3oi,02.  startSmallJobs^  oi 
iS>  StartLarge  Jobs— >  02 
(8)  Range{0, 10) 

(8)  02@k2  Range{ll,  100) 

public  Producer 

(Link  ss.  Link  si. 

Link  es.  Link  el)  { 

startSmallJobs  =  ss; 
StartLarge Jobs  =  si; 


public  void  produce ( ) 
this@k  BothInRange{)  — o 
this@k  BothlnRangeQ  { 

Random  generator  =  new  Random ( ) 
int  r  =  generator . next Int  ( 1 0 1 )  ; 
Link  1  =  new  Link  (r,  null); 
if  ( r  <=  1 0 ) 

{  if  (startSmallJobs  ==  null) 

{  startSmallJobs  =  1; 
endSmallJobs  =  1; } 

else 

{ endSmallJobs . next  =  1; 
endSmall Jobs=  1;} 

} 

else 

{  if  ( StartLarge Jobs  ==  null) 

{  StartLarge Jobs  =  1; 
endLarge Jobs  =  1; } 

else 

{ endLarge Jobs . next  =  1; 
endLargeJobs  =  1;} 


} 


predicate  ConsumeInRange ( int  x,  int  y) 
start  Jobs^  o  (81  o@k  Range{x,y) 

public  Consumer (Link  s)  { 
startJobs  =  s; 

public  void  consume () 

V  X : int ,  y : int . 

this@k  ConsumeInRange{x,y) 

—o  this@k  ConsumelnRange{x,y) 

{  if  (startJobs  !=  null) 

{ System . out .println(startJobs.val) 
startJobs  =  start Jobs . next ; } 

} 


Figure  12:  Consumer  class 

public  class  Control  { 

Producer  prodl,  prod2 ; 

Consumer  consl,  cons2; 

predicate  WorkingSystem ( )  = 

prodl— >•  oi®  prod2— >■  02 

(8)  consl— >■  03(8)  cons2  -^04 
8  oi@ki  BothInRangeO 
8  02@k2  BothInRangeO 
8  os@k^  ConsumeInRange{0, 10) 

8  04@A;4  ConsumeInRange{ll,100) 

public  Control  (Producer  pi.  Producer  p2 
Consumer  cl.  Consumer  c2 )  { 

prodl  =  pi;  prod2  =  p2; 
consl  =  cl;  cons2  =  c2;  } 


public  void  makeActive (  int  i) 

this@k  WorkingSystemO 

this@k  WorkingSystemO  i 

Random  generator  =  new  Random () ; 
int  r  =  generator . next Int  ( 4 ) ; 
if  (r  ==  0)  { prodl . produce  0;  } 

else  if  (r  ==  1)  { prod2 . produce (); } 

else  if  (r  ==  2)  { consl . consume ( ) 

else  {  cons2  .  consume  0;  } 
if  (i  >  0)  {  makeActive ( i-1 ); } 
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Figure  11:  Producer  class 


it  expects  the  queues  to  be  shared  with  other  objects,  but  also  that  the  elements  of  one  queue  will 
stay  in  the  range  [0,10],  while  the  elements  of  the  second  queue  will  stay  in  the  range  [1 1,100]. 

Now,  let’s  imagine  changing  the  code  to  reflect  the  modifications  in  the  right  image  of  Figure 
10.  The  internal  representation  of  the  predicates  changes,  but  their  external  semantics  stays  the 
same:  the  producers  produce  jobs  and  they  direct  them  to  the  appropriate  queue,  each  consumer 
accesses  only  one  kind  of  queue  (either  the  queue  of  small  jobs  or  the  queue  of  big  jobs),  and 
the  controller  is  still  the  manager  of  the  system.  The  predicate  BothInRange  ()  of  the  Pro¬ 
ducer  class  is  exactly  the  same.  The  predicate  Consume InRange  (x,  y )  of  the  Consumer  class 
changes  to 

ConsumeInRange  (x,  y )  =  start  Jobsl^- Oi0  start  Jobs2^- O2 
®  Oi@k  Range{x,y)  ®  02@k  Range{x,y). 

The  predicate  WorkingSystem  ( )  of  the  Control  class  does  not  change. 

The  local  changes  did  not  influence  the  specification  of  the  Control  class,  thus  conferring 
greater  flexibility  and  modularity  to  the  code. 

The  current  separation  logic  approaches  do  not  provide  this  modularity.  Distefano  and  Parkin¬ 
son  [9]  introduced  jStar,  an  automatic  verification  tool  based  on  separation  logic  aiming  at  pro¬ 
grams  written  in  Java.  Although  they  are  able  to  verify  various  design  patterns  and  they  can  define 
abstract  predicates  that  hide  the  name  of  the  fields,  they  do  not  have  a  way  of  hiding  the  aliasing.  In 
all  cases,  they  reveal  which  references  point  to  the  same  shared  data,  and  this  violates  the  informa¬ 
tion  hiding  principle.  By  using  access  permissions,  we  can  hide  what  is  the  data  that  two  objects 
share.  We  present  the  specifications  needed  to  verify  the  code  in  Figure  10  using  separation  logic. 
The  predicate  for  the  Producer  class  is  Prod{this,  ss,  es,  si,  el),  where  : 

Prod[p,  ss,  es,  si,  el)  =  p.startSmallJobs  ss  -k  p.endSmallJobs  es  -k 
p. start  Large  Jobs  si  -k  p.endLargeJobs  — >•  el. 

The  precondition  for  the  produce  ( )  method  is: 

Prod{p,  ss,es,  sl,el)  -k  Listseg{ss,  null,  0,10)  k  Listseg {si,  null,  11, 100). 

The  predicate  for  the  Consumer  class  is 
Cons{c,  s)  =  c  ^  s. 

The  precondition  for  the  consume  ( )  method  is: 

Cons{c,s)  -k  Listseg{s, null, 0,10). 

The  predicate  for  the  Control  class  is  : 

Ctrl{ct,pl,p2,cl,c2)  =  ct.prodl  pi  -k  et.prod2  -^p2-k 
ct.consl  cl  k  ct.cons2  — >  c2. 

The  precondition  for  makeAct  ive  ( )  is: 

Ctrl{this,pl,p2,cl,c2)  -k  Prod{pl,  ss,es,  sl,el)  -k  Prod{p2,  ss,es,  sl,el)  -k 
Cons{cl,  si)  -k  Cons{c2,  ss)  k  Listseg{ss,  null,  0,10)  k  Listseg{sl,  null, 11, 100). 

The  lack  of  modularity  will  manifest  itself  when  we  add  the  two  queues  as  in  the  right  image 
of  Figure  10. 

The  predicates  Prod{p,  ss,  es,  si,  el)  and  Ctrl{ct,  pl,p2,  cl,  c2)  do  not  change,  while  the  pred¬ 
icate  Cons{c,  si,  s2)  changes  to 

Cons{c,  si,  s2)  =  c. start  Jobsl  si  k  c. start  Jobs2  — >  s2. 

The  precondition  for  the  consume  ( )  method  becomes: 
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Cons{c,  si,  s2)  ic  Listseg{sl,  null,  0,10)  ★  Listseg{s2,  null,  0,10). 

Although  the  behavior  of  the  Consumer  and  Producer  classes  have  not  changed,  the  precondi¬ 
tion  for  makeAct  ive  ( )  in  class  Control  does  change: 

Ctrl{this,pl,p2,cl,c2)  -k  Prod{pl,  ssl,esl,  sll,ell)  -k  Prod{p2,  ss2,es2,  sl2,el2)  -k 
Cons{cl,  sll,  sl2)  k  Cons{c2,  ssl,  ss2)  k  Listseg{ssl,  null,  0, 10)  k 
Listseg{ss2,  null,  0,10)  k  Listseg{sll,  null,  11, 100)  k  Listseg{sl2,  null,  11, 100) 

The  changes  occur  because  the  pointers  to  the  job  queues  have  been  modified  and  the  separation 
logic  specifications  have  to  reflect  the  changes.  This  leads  to  a  loss  of  modularity. 


8  Composite 

The  Composite  design  pattern  [11]  expresses  the  fact  that  clients  treat  individual  objects  and  com¬ 
positions  of  objects  uniformly.  Verifying  implementations  of  the  Composite  pattern  is  challenging, 
especially  when  the  invariants  of  objects  in  the  tree  depend  on  each  other  [18],  and  when  interior 
nodes  of  the  tree  can  be  modified  by  external  clients,  without  going  through  the  root.  As  a  result, 
verifying  the  Composite  pattern  is  a  well-known  challenge  problem,  with  some  attempted  solu¬ 
tions  presented  at  SAVCBS  2008  (e.g.  [4,  15]).  We  describe  a  new  formalization  and  proof  of  the 
Composite  pattern  using  fractions  and  object  propositions  that  provides  more  local  reasoning  than 
prior  solutions.  For  example,  in  Jacobs  et  al.  [15]  a  global  description  of  the  precise  shape  of  the 
entire  Composite  tree  must  be  explicitly  manipulated  by  clients;  in  our  solution  a  client  simply  has 
a  fraction  to  the  node  in  the  tree  it  is  dealing  with. 

We  implement  a  popular  version  of  the  Composite  design  pattern,  as  an  acyclic  binary  tree, 
where  each  Composite  has  a  reference  to  its  left  and  right  children  and  to  its  parent.  The  code  is 
given  below. 

public  class  Composite  { 

private  Composite  left  ,  right  ,  parent  ; 
private  int  eount  ; 

public  CompositeO 

{ 

this. count  =  1 ; 
this  .left  =  null  ; 
this  .  right  =  null  ; 
this  .  right  =  null  ; 

} 

private  void  updateCountRec  () 

{ 

if  (this. parent  !=  null) 

{ 

this  .  updateCount  (); 

this  .  parent  .  updateCountRec  ( ) ; 
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} 

else 

this  .  updateCount  (); 

} 

private  void  updateCount() 

{ 

int  newc  =  1; 
if  (this. left  !=  null) 

newc  =  newc  +  left. count; 
if  (this. right  !=  null) 

newc  =  newc  +  right. count; 
this. count  =  newc ; 

} 


public  void  setLeft  ( Composite  1) 

{ 

1 . parent=  this; 

this .left  =  1 ; 

this.  updateCountRec  ( ) ; 

} 

public  void  setRight  ( Composite  r){ 
r . parent  =  this; 
this  .  right  =  r  ; 
this.  updateCountRec  ( ) ; 

} 

} 

Each  Composite  caches  the  size  of  its  subtrees  in  a  count  field,  so  that  a  parent’s  count  depends  on 
its  children’s  eount.  The  dependency  is  in  fact  recursive,  as  the  parent  and  right/left  child  pointers 
must  be  consistent.  Clients  can  add  a  new  subtree  at  any  time,  to  any  free  position  (where  the 
current  reference  is  null).  This  operation  changes  the  count  of  all  ancestors,  which  is  done  through 
a  notification  protocol.  The  pattern  of  circular  dependencies  and  the  notifieation  mechanism  are 
hard  to  capture  with  verification  approaches  based  on  ownership  or  uniqueness. 

We  assume  that  the  notification  terminates  (that  the  tree  has  no  cycles)  and  we  verify  that  the 
Composite  tree  is  well-formed:  parent  and  child  pointers  line  up  and  counts  are  consistent. 

Previously  the  Composite  pattern  has  been  verified  with  a  related  approach  based  on  aecess  per¬ 
missions  and  typestate  [4].  This  verifieation  abstracted  counts  to  an  even/odd  typestate  and  relied 
on  non-formalized  extensions  of  a  formal  system,  whereas  we  have  formalized  the  proof  system 
and  provide  a  full  proof  in  the  supplemental  material.  Our  verification  proves  partial  correctness 
of  this  version  of  the  Composite  pattern. 
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predicate  count  (int  c)  =  3ol,  or,  Ic,  rc.  this.count  c  0 

c  =  Ic  +  rc  +  1  ®  this@i  ^e/t(ol,  Ic) 

(g)  this@^  right{or,  rc) 


predicate  left  (Composite  ol,  int  Ic)  =  this. left  ^  ol  0 
((ol  ^  null  ^  count{\c)) 

©  (ol  =  null  ^  Ic  =  0)) 


predicate  right  (Composite  or,  int  rc)  =  this. right  or  © 
((or  ^  null  ^  count{rc)) 

©  (or  =  null  ^  rc  =  0)) 


predicate  parent  ()  =  3op,  c,  k.  this. parent  ->  op  i 


op  ^  this 


this@-  count{c)  © 


^(op^null  ^  op@W parentQ 
(op@^  left{th\s,  C) 

©  op@^  right{\h\S,  c)))® 


(op  =  null 


this@-  count{c 


Figure  14:  Predicates  for  Composite 


8.1  Specification 

A  Composite  tree  is  well-formed  if  the  field  count  of  each  node  n  contains  the  number  of  nodes  of 
the  tree  rooted  in  n.  A  node  of  the  Composite  tree  is  a  leaf  when  the  left  and  right  fields  are  null. 

The  goals  of  the  specification  are  to  allow  clients  to  add  a  child  to  any  node  of  the  tree  that  has 
no  left  (or  right)  child.  Since  the  count  field  of  a  node  depends  on  the  count  fields  of  its  children 
nodes,  inserting  a  child  must  not  violate  the  transitive  parents’  invariants. 

We  use  the  following  methodology  for  verification:  each  node  has  a  fractional  permission 
to  its  children,  and  each  child  has  a  fractional  permission  to  its  parent.  We  allow  unpacking  of 
multiple  object  propositions  as  long  as  they  satisfy  the  heap  invariant:  if  two  object  propositions 
are  unpacked  and  they  refer  to  the  same  object  then  we  require  that  they  do  not  have  fields  in 
common. (Note  that  the  invariant  needs  to  hold  irrespective  of  whether  the  object  propositions  are 
packed  or  unpacked.) 

The  predicates  of  the  Composite  class  are  presented  in  Figure  14. 
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The  predicate  count  has  a  parameter  c,  which  is  an  integer  representing  the  value  at  the  count 
field.  There  are  two  existentially  quantified  variables  Ic  and  rc,  for  the  count  fields  of  the  left  child 
Ic  and  the  right  child  rc.  By  c  =  /c  +  rc  +  1  we  make  sure  that  the  count  of  this  is  equal  to  the  sum 
of  the  counts  for  the  children  plus  1.  By  this@^  left{o\,  Ic)  0  this@^  rightipx,  rc)  we  connect  Ic 
to  the  left  child  (through  the  left  predicate)  and  rc  to  the  right  child  (through  the  right  predicate). 

The  predicate  left  expresses  that  the  predicate  countifc)  holds  for  this.left,  the  left  child  of 
this.  The  predicate  right  expresses  that  the  predicate  count{rc)  holds  for  this.right,  the  right 
child  of  this.  The  permission  for  the  left  (right)  predicate  is  split  in  equal  fractions  between  the 
count  predicate  and  the  left  (right)  child’s  parent  predicate. 

Inside  the  parent  predicate  of  this,  there  is  a  fractional  permission  to  the  count  predicate  (and 
implicitly  to  its  count  field)  of  this.  The  parent  predicate  contains  only  a  fraction  of  A;  <  |  to 
the  parent  of  this  so  that  any  clients  can  use  the  remaining  fraction  to  reference  the  node  and  add 
children  to  the  parent.  A  client  can  actually  use  this  to  update  the  parent  field,  but  in  order  to  pack 
the  parent  predicate,  the  client  has  to  conform  to  the  well-formedness  condition  mentioned  earlier. 

If  a  new  node  is  added  to  the  tree  as  the  left  child  of  this,  we  need  to  change  the  count  field  of 
this.  The  field  left  of  this  must  be  null  and  the  permission  with  a  half  fraction  has  to  be  acquired 
by  unpacking  the  count  predicate  of  this.  This  requires  us  to  unpack  the  parent’s  left  predicate, 
which  requires  the  parent’s  count  predicate,  and  so  on  to  the  root  node.  We  can  only  pack  it  back 
when  the  tree  is  in  a  well-formed  state.  As  the  notification  algorithm  goes  up  the  tree,  from  the 
current  node  to  the  root,  we  successively  unpack  the  predicates  corresponding  to  each  node  and  we 
pack  them  back  when  the  tree  is  well-formed.  This  ensures  that  if  a  new  node  is  added,  in  order  to 
pack  the  predicates  again,  the  count  fields  must  be  updated  and  consistent! 

The  proof  of  partial  correctness  of  the  Composite  pattern  is  presented  in  the  supplemental 
material.  The  proof  is  currently  done  by  hand. 

The  complete  specification  for  each  method  is  given  below: 

class  Composite  { 

private  Composite  left  ,  right  ,  parent; 

private  int  count  ; 

public  Composite 
^  this®  ^  parentO  (g) 

this@f  left(null,  0)  (g)  this@f  right(null,  0) 


private  void  updateCountRec  () 

3  kl.  (unpacked(this@  kl  parent())  g 

=1  opp,  ICC,  k<f  .unpacked(this@^  count(lcc)) 

gthis. parent  ^  opp  g  opp  this  g 

^(opp  f  null  ^  opp@k  parentO  g 

(opp®^  left(this,  Icc)  ©  opp@f  right(this,  Icc)))  © 

(opp  =  null  ^  this@i  count(ICC))  j  g 
3  ol,  Ic,  or,  rc,  Icc'.  this. count  ^  Icc  g  Icc’  =  Ic  -i-  rc  +  1  g 
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this@i  left(ol,  Ic)  ®  this@^  right(or,  rc) 

^  this@kl  parentO) 

{•••} 

private  void  updateCount  () 

=1  C,  C1 ,  c2,  nc.  unpacked(this @  1  count(c))  ® 
this. count  ^C(8)c  =  cl+c2+l(8) 

3  ol,  Ic,  or,  rc.  this@|  left(ol,  Ic)  (g> 
this@^  right(or,  rc)  (8) 

3  k1 .  unpacked(this@/cl  parentO) 

^  this@l  count(nc)  0 

nc  =  Ic  +  rc  +  1  0  3  fc.  unpacked(this@k  parentO) 

{...} 

public  void  setLeft  (Composite  1) 
this  ^  I  0 

3k2.(3  kl.this@kl  parentO  0  l@k2  parentO  0 
this®  I  left(null,  0)  ^ 

3  k.this@k  parentO  0  l@k2  parentO) 

(...) 

} 

The  constructor  of  the  class  Composite  returns  half  of  the  permission  for  the  left  and  right 
predicate,  and  half  of  a  permission  to  the  parent  predicate. 

The  method  updateCount  Reef)  takes  in  a  fraction  of  kl  to  the  unpacked  parent  predicate  and 
a  half  fraction  to  the  unpacked  count  predicate  of  this,  and  it  returns  the  kl  fraction  to  the  packed 
parent  predicate.  This  means  that  after  calling  this  method,  the  parent  predicate  holds  for  this. 

In  the  same  way,  the  method  updateCount  takes  in  the  unpacked  predicate  count  for  this 
object  and  it  returns  the  count  predicate  packed  for  this.  Thus,  after  calling  updateCountQ,  the 
object  this  satisfies  its  count  predicate. 

The  method  setLeft{Composite  1)  takes  in  a  fraction  to  the  parent  predicate  of  this,  a  frac¬ 
tion  to  the  parent  predicate  of  I  and  the  left  predicate  of  this  with  a  null  argument  (saying  that 
the  left  field  of  this  is  null  and  thus  a  client  can  attach  a  new  left  child  here).  The  post-condition 
shows  that  after  calling  setLeft,  some  of  the  permission  to  the  parent  predicate  of  this  has  been 
consumed,  while  the  fraction  to  the  predicate  parent  of  I  stays  the  same. 


9  Dynamic  Semantics  and  Soundness 

The  dynamic  semantics  for  our  language  is  given  in  Figure  15.  Below  we  describe  the  definitions 
used  for  dynamic  semantics  support. 
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Lookup 


Let-e 


Let-0 


li,p,l  -)•  p,p,p(l) 

o  ^  dom{fi)  fx'  =  fi[o  C{p{l))] 

- z -  New 

p.,  p,new  C{1)  p',p,o 

p,  p,  ei  p' t  p'  y  e' 

p,  p,  let  X  =  ei  in  €2  — >•  p' ,  p' ,  l^t  x  =  e'  in  62 
I  ^  dorn(p) 

p,  pylet  X  =  o  in  62  — >  Py  p[l o]y[l/x]e2 

V  €  {nullyn,  true,  false} 

- ^ - r~r~^ —  let-v 

Py  pylet  X  =  V  in  62  — >■  pyp,[v/x\e2 

p{p{ll))  =  C(o)  fieldi^iC)  =  Tf 

p,p,h-f  =  h  -5-  p[p{h)  [p{l2)/or]C{o)],p,p(l2) 

- 77 - ^ ; -  IF-TRUE 

Py  pylj  [true)  ei  else  62  — >  /i,p,  ei 


Assign 


Py  py  if  (false)  ei  else  62  p,  p,  62 

p{p{h))  =  C{o) 

method(m,  C)  =  Tr  m{x){return  e} 
p,  p,li -1x1(12)  p,  p,[h/this,l2/xi]£ 
p(p(l))  =  C{o)  fields(C)  =  Tf 


IF-FALSE 


Invoke 


p,p,l-fi  P,P,Oi 


Field 


p,  p,pack  r@k  Ri  in  ei  — >  p,p,ei 


Pack 


p,  p,  unpack  r@k  Ri  in  e\  — >•  p,p,e\ 


Unpack 


Figure  15:  Dynamic  Semantics  Rules 
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•  Pi  =  unpacked{o@ki  Q)  G  P  ^  ^  P  that  Pj  =  unpacked{o@k2  Q) 

•  Vo,  Q  Ylio^=o  Qi=Q  where  Oi@ki  Qi  or  unpacked{oi@ki  Qi) 

•  \/i,j  such  that  pre(i(Pi)  ^  pred{Pj),  fields{def{pred{Pi),Ci))  D  fields{def{pred{Pj),Cj))  = 
0,  where  fields{o.f  — >■  o')  =  /,  pred{o.f  — )■  o')  =  0,  pred{o@k  Q)  =  Q  and 
pred{unpacked{o@k  Q))  =  Q 

Figure  16:  Heap  Invariants 

C{o)  G  Objects 

ji  G  r  Objects  (stores) 

p  G  i  Values  (environments) 

P(n)  ::=  (/  U  r  U  u)  -w  R  (propositions) 

S  ::=  r  Predicate  (store  types) 

r  G  ObjectRefs 

I  G  IndirectRefs 

V  G  Variables 

R  G  Object  Propositions 

The  semantics  is  a  mostly-standard  small-step  operational  semantics;  the  rules  are  complete 
except  for  standard  rules  to  reduce  binary  and  logical  operators.  We  define  the  judgement  p,  p,e  — > 

The  main  interesting  feature  is  the  use  of  indirect  references,  a  proof  technique  adapted  from 
[25].  The  Let-0  rule  shows  that  when  the  left-hand  expression  of  a  let  reduces  to  a  reference  o, 
instead  of  substituting  o  for  x,  we  allocate  a  fresh  indirect  reference  I,  and  add  a  mapping  from  I 
to  o  in  an  environment  p.  The  LOOKUP  rule  later  reduces  I  to  an  o,  so  that  execution  is  isomorphic 
to  a  standard  substitution-based  semantics.  However,  the  use  of  the  p  enviroment  allows  us  to 
distinguish  references  that  came  from  different  variables,  because  they  will  have  different  indirect 
references  /.  This  is  useful  for  preservation,  because  the  original  variables  may  have  had  different 
permissions,  and  we  need  to  preserve  those  different  permissions  when  the  variables  are  substituted 
with  indirect  references.  S  maps  a  reference  to  a  predicate.^  will  contain  actual  values  for  the 
arguments  of  the  predicates,  since  S  is  used  at  runtime. 

The  h  PR  represents  the  judgement  that  a  program  PR  is  well  formed,  meaning  that  all 
methods  obey  their  specification.  There  are  necessary  helper  judgements  for  Program,  Class 
and  Method.  For  space  reasons,  we  do  not  present  them  here. 

We  define  the  consistency  of  the  heap  and  environment,  along  with  the  semantics  of  predicates 
using  the  judgment  p,  S,  Fiji),  p  \-  o  ok.  We  check  consistency  for  each  reference  o.  For  space 
reasons,  we  do  not  give  the  technical  details  o  how  we  do  this. 

We  do  mention  that  in  order  to  prove  that  the  invariants  ofP  hold  (that  the  heap  is  in  a 
consistent  state),  where  P  =  objPropsip,  E,  F(n),  p,  o),  the  conditions  in  Figure  16  have  to  hold. 
Note  that  in  the  third  condition  of  Figure  16  def  looks  up  the  definition  of  the  predicate  of  Pi  in 
the  defining  class  Ci. 

Now  we  state  the  main  preservation  theorem  that  underlies  the  soundness  of  our  system: 
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(Preservation  Theorem) 

If  F;  n  h  e  :  3x.T ;  R  and  fi,  E,  -F(n),  p  ok  and  pL,p,e  ^  p',  p',  e'  and  h  PR  then  there  exists 
n' ,  F'  and  S'  such  that  F';  H'  h  e'  :  Bx.T;  R  and  p',  S',  F(n'),  p'  ok. 

The  proof  uses  induction  over  the  derivation  of  p,  p,e  p',  p',  e!  in  the  standard  way.  In  the 
proof,  If  and  11'  do  not  contain  the  0  symbol.  If  the  ©  symbol  is  added  to  these  contexts,  it  is 
straightforward  to  use  induction  to  prove  preservation. 

9.1  Proving  the  Preservation  Theorem 

Lemma  1  (Substitution)  If  {T^y  :  Ty);  (IIi  0  Ry)  h  e  :  3x.T;  R  and  F;  112  h  f  :  3x.Ty;  \t/y\Ry 
then  F;  ([f/yjlli  0  II2)  H  [t/y\e  :  3x.T;  [tly\R. 

Proof  of  Substitution  Lemma 

The  proof  is  by  induction  on  the  derivation  of  (F,  y  :  Ty)]  (Hi  0  Ry)  h  e  :  3x.T ;  R.  Note  that 
there  is  a  clear  correspondence  between  the  structure  of  e  and  which  rule  is  used  to  type  it.  Thus 
the  cases  are  on  the  structure  of  e  rather  than  the  rule  by  which  the  typing  judgement  was  dehned. 
In  the  proof,  111  and  112  do  not  contain  the  0  symbol.  If  the  0  symbol  was  added  to  these  contexts, 
it  would  be  straightforward  to  use  induction  to  prove  the  lemma  using  the  rule  0. 

1.  e  is  a  value  v.  The  values  that  e  can  take  in  this  case  are  null\true\false\n.  We  know 
(F,  y  :  Ty),  (Fli  0  Ry)  h  u  :  3x  :  T.R.  Since  u  is  a  value,  R  will  be  trivially  equal  to  v. 
Thus  y  does  not  appear  in  R  and  R  =  \t/y]R.  Because  \ei/y]e  =  v  we  trivially  obtain  that 

2.  e  is  a  variable  f  y.  We  know  (F,  y  :  Ty)]  (FIi  0  Ry)  h  z  :  3x.T;  R.  Since  z  f  y,  we 
know  by  inversion  that  R  E  FIi,  with  R  =  z@k  Q{ti)  and  Q{ti)  might  contain  p  as  a  free 
variable.  Thus  [t/y]R  E  \t/y\Ili  and  [t/y]e  =  z.  We  can  deduce  that  F;  ([f/yjlli  0  FI2)  F 
z  :  3x.T\  [t/y]R. 

3.  e  is  the  variable  y.  Now  {t/y]e  —  t  and  T  —  Ty  and  R  =  Ry.  Thus,  F;  ([t/y]Yii  0  FI2)  F  t  : 
3x.T]  [t/y]R. 

4.  e  is  r./j.  We  know  that  (F,  y  :  Ty);  (If  0  Ry)  F  r.f  :  3x.T;  R.  We  also  know  by  inversion 
that  n  0  F  r.  fi  and  that  F;  (FI  0  Ry)  F  [ri/x]R.  Using  the  induction  hypothesis 
we  have:  i[t/y]Il  0  112)  F  [t/y]{r.f  -E  rf  and  F;  {[t/y]Il  0  FI2)  F  [t/y][r.,/x]R.  Since  r.f 
is  just  the  syntactic  representation  of  a  field,  the  substitution  will  happen  in  rp  ([f/p]Fl  0 
1^2)  F  (r.fi  -E-  [t/y]ri).  Also,  we  can  rewrite  [t/y][ri/x]R  as  [{[t / y]ri) / x][t / y]R  and  so 
we  have  F;  ([t/y]Il  0  FI2)  F  [{[t /y]ri) / x][t /y]R.  Using  the  rule  (Field),  we  obtain  that 
F;  ([f/p]Fl  0  FI2)  F  [t/y]r.fi  :  3x  :  T.[t/y]R,  exactly  what  we  wanted. 

5.  e  is  new  C(ti).  We  know  (F,y  :  Ty);  (FI  0  Ry)  F  new  C{ti)  :  3z.C;z.f  — >  R.  We 
also  know  by  inversion  that  (F,  y  :  Ty)  \-  R  -.T.  Using  the  induction  hypothesis  we  have 
F  F  [t/y]ti  :  T.  Using  the  rule  (New),  we  obtain  that 

T;  ([f/y]n  0  112)  F  [f/y]new  (7(fi)  : 

3z.C';  z.f  — )•  [t/y]ti,  exactly  what  we  wanted. 
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6.  e  is  if  (ti )  { ei }  else  { 02  } .  We  know  (F,  y  :  Ty)]  (11  0  Ry)  h  if  (ti )  { ei }  else  { 62  }  : 

3x.T;  Ri  ©  i?2.  We  also  know  by  inversion  that  (T,y  ;  T^);  (J1  ®  Ry  ®  R  =  true)  h 
01  :  3x.T;i?i  and  that  (F,^  :  Ty);  (11  0  0  ti  =  false)  h  02  :  3x.T;R2.  Using  the 

induction  hypothesis  and  knowing  that  F,n2  H  t  :  3x.Ty;  [t/y]Ry,  we  have  F;  {[t/y]Il  0 
II2  0  =  true)  h  [t/y]ei  :  3x.T;  [t/y]Ri  and  that  F;  {[t/y]Il  0  112  0  ti  =  false)  h 

[t/y]ei  :  3x.T;  [t/y]R2.  By  applying  the  (If)  rule,  we  obtain  that  F;  ([t/y]n  0  112)  b 
if  (ti)  {ei}else{e2}  :  3x.T;  [t/y]Ri  ©  [t/y]R2.  Since  [t/y]Ri  ©  [t/y]R2  =  [t/y]{Ri  © 
/?2)  we  obtain  that  F;  ([t/y]n  0  112)  b  if  (ti )  { 01 }  else  { 02  }  :  3x.T][t/y]{Ri  Q)  R2), 
exactly  what  we  wanted. 

7.  0  is  let  x  =  01  in  02.  We  know  (F,  y  :  Ty)]  (11  0  Ry)  b  let  x  =  01  in  02  :  3uj.T2;  R.  We 
also  know  by  inversion  that  (F,  y  :  Ty)]  (11 0  Ry)  b  01  :  3x.Ti;  Ri  0 112.  Using  the  induction 
hypothesis  and  knowing  that  F;  lls  b  t  :  3x.Ty]  [t/y]Ry,  we  obtain  that  F;  {[t/y]Il  0  lls)  b 
[t/y]ei  :  3x.Ti]  [t/y]{Ri  0  112).  We  also  know  by  inversion  that  (F,r/  :  Ty,x  :  Ti);  (i?i  0 
112)  b  02  :  3w.T2]R2.  This  means  that  (F,  x  :  Ti);  (FIs  0  [t/y]Ri  0  [t/y]Il2)  b  [t/y]e2  : 
3W.T2]  [t/y]R2.  Now,  we  can  apply  the  (Let)  rule  and  we  obtain  that  F;  {[t/y]Il  0  lls)  b 
[t/y]{let  X  —  ei  in  02)  :  3w.T2][t/y]R,  which  is  exactly  what  we  wanted. 

8.  0  is  pack  r@k  Q{ti)  in  e,  with  0  <  k  <  1.  We  know  that  F;  11  b  pack  r@k  Q{ti)  in  0  : 
3x.T;  R.  We  also  know  by  inversion  that  F;  (lli  0  r@k  Q{ti))  b  e  :  3x.T;  R.  Using  the 
induction  hypothesis  and  knowing  that  F;  112  b  0  3x.Tj^;  [t/y]Ry,  we  obtain  that 

F;  {[t/y\{Yii  0  r@k  Q{ti))  0  112)  b  \t/y]e  ;  3x.T;  \t/y]R.  The  other  two  premises  of  the 
(Pack2)  rule  can  also  be  obtained  by  inversion  and  they  remain  the  same.  From  the  first 
premise  F;  11  b  r  :  (7;  [ti/x]Ri  0  unpacked(r@k  Q(U))  ®  Hi  we  can  deduce  by  induction 

that  F;  {[t/y]Yl  0  112)  b  [t/y]r  :  C]  [t/y]{[ti/x]Ri  0  unpacked(r@fc  Q(U))  ®  Hi) 

So  now  we  can  apply  the  (Pack2)  rule  again  and  we  get  that 

T;  ([Vy]n  0  112)  b  [t/y](pack  r@k  {Q{ti)))  in  [t/y\e  :  3x.T;  [t/y\R. 

Thus,  F;  ([t/y]n  0  112)  b 

[t/y\{psiC\r@k  Q{ti)  in  0)  :  3x.T;  [t/y\R,  exactly  what  we  wanted. 

9.  0  is  pack  r@l  (52(^2)  xn  e.  The  proof  in  this  case  is  analogous  to  the  one  for  the  previous 
case,  but  the  fraction  k  will  be  replaced  by  1  across  the  proof. 

10.  0is  unpack  r@k  Q{ti)  in  efor  0  <  fc  <  1.  We  know  that  F;  11  b  unpack  r@k  Q{ti)  in  0  : 
3x.T ;  R.  We  also  know  by  inversion  that  F ;  (lli  0  [fi/T]7?i0 

unpacked(r@fc  Q{ti))  b  e  :  3x.r;  R.  Using  the  induction  hypothesis  and  knowing  that 
F;  112  b  t  :  3x.Ty]  [t/y]Ry,  we  obtain  that 
T]{[t/y]{Ili  0  [U/T]i?i0 

unpacked(r@fc  Q(ti))0n2)  b  [t/y]e  :  3x.T;  [t/y]R.  The  other  premises  of  the  (Unpack2) 
rule  can  also  be  obtained  by  inversion  and  they  remain  the  same.  From  the  first  premise 
F;n  b  r  :  C]r@k  Q{ti)  0  lli  we  obtain  by  induction  that  F;  {[t/y]Il  0  112)  b  [t/y]r  : 
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C;  [t/y\{r^k  Q{ti)  ®  Hi).  Now  we  can  apply  the  (Unpack2)  rule  again  and  we  get 
that  F;  ([t/y]n  0  112)  F  unpack  [t/y]r@/c  \t/y\Q{ti)  in  \t/y\e  :  3x.T]\t/y\R.  Thus 
r;([t/y]n0n2)h 

[t/y] (unpack  r@k  in  Q{ti))  in  [t/y]e  :  3x.T;  [t/y]R,  exactly  what  we  wanted  to  prove. 

11.  e  is  unpack  r@l  Q(ti)  in  e.  The  proof  in  this  case  is  analogous  to  the  one  for  the  previous 
case,  but  the  fraction  k  will  be  replaced  by  1  across  the  proof. 

12.  e  is  ro.m(ti).  We  know  that  F;  Ft  h  ro.m(fi)  : 

3result.Tr]  [ro/this][ti/x]R<^Ili.  We  know  by  inversion  that  F;  Ft  h  [ro/this][ti/x]Ri0lli. 
Using  the  induction  hypothesis  and  knowing  that 

F,  Ft2  F  f  :  3x.Ty-,  [t/y]Ry,  we  obtain  that 

F;  ([f/y]Ft  0  112)  F  [t/y]{[ro/this][ti/x]Ri  0  Fti).  This  is  equivalent  to  writing 
F;([f/?/]Ft0Ft2)  F  [ro/this][[t/y]ti/x][t/y]Ri®[t/y]Ili. 

By  inversion  we  know  that  F  F  tq  :  Co  and  F  F  :  T.  Using  the  induction  hypothesis 
we  obtain  that  F  F  [t/y]ro  :  Cq  and  F  F  [t/y]ti  :  T.  Also  by  inversion  we  know  that 
mtype{m,  Cq)  =  \/x  :  T.3result.Tr]  R[  — o  R  and  RiimpliesR'i. 

We  can  infer  that  [t/y]Ri  F  [t/y]R[  and  that 

mtype{m,  Cq)  =  Mx  :  T.3result  :  T^-R'i  —o  R  will  hold  for  [t/y]ti  :  T  (because  of  the  V 
quantifier  of  the  (Mtype)  judgement).  We  can  now  apply  the  (Call)  rule  again  and  we 
obtain  that 

T-,{[t/y]U<^U2)  F  {{[t/y]ro).m{[t/y]ti))  : 

3  result.Tr]  [[t/y\rQ/this\[[tjy\tim[t/y\R®  [t/y]Fti. 

Since  rQ.m{[t/y]ti)  =  [t/y]{ro.m{ti))  and 

[rQ/this][[t/y]ti/x][t/y]R  =  [t/y]{[rQ/this][ti/x]R),  we  obtain  that  T]  {[t/y]Il  ®  II2)  F 
[t/y]{rQ.m{ti))  :  3  result.Tp,  [t/y]([ro/t/ws][fi/x]i?  0  \t/y]Yii).  This  is  exactly  what  we 
wanted  to  prove. 


13.  e  is  Ti-fi  —  ti.  We  know  that  F;  Ft  F  {ri.fi  —  U)  : 

Bx.Tp  x@k'  Q'{t')  0  ti@kQ  (5o(^o)  ®  Ti-fi  ti®  FIs.  We  know  by  inversion  that  F;  FI  F 
ti  :  Ti]  ti@ko  Qo{to)  0  III.  Using  the  induction  hypothesis  and  knowing  that  F;  FI4  F  f  : 
3x.Ty]  [t/y]Ry,  we  obtain  that  F;  ([t/y]FIi  0  FI4)  F  [t/y]ti  :  Tp,  [t/y]{ti@ko  Qo{to)).  This 
means  that 

[t/y]{ti@ko  Qo{to))  =  {[t/y]ti)@ko  [t/y]Qo{tQ).  The  other  premises  of  the  (Assign)  rule 
can  also  be  obtained  by  inversion.  From  the  second  premise  F;  FIi  F  ri.fi  ■  Tp  r{@k'  Q'{t')® 
FI2  we  get  by  induction  that  F;  ([f/y]FIi  0  FI4)  F  ri.fi  '■  Tp  [t/y]{r{@k'  Q'{t')  0  FI2).  From 
the  third  premise  FI2  F  ri./j  r'  0  FI3  we  get  by  induction  that  {[t/y]Il2  ®  FI4)  F  ri.fi 
[t/y]r{  0  [t/y]Il3.  So  now  we  can  apply  the  (Assign)  rule  again  and  we  get  that  T]  {[t/y]Il® 
F[4)  F  ri.fi  =  [t/y]ti  :  3x.Tp  [t/y]{x@k'  Qfi'))  0  [t/y]{t@ko  Qo{R))  0  ri.fi  ^  [Vy]C)- 
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Since  (ri./i  =  [t/y]ti)  =  {[t/y]{ri.fi  =  ^))  and  Qo(io))®  ri.f, 

[t/y]ti  =  \t/y]{x@k' Q'{t')  ®t@kQ  QQ{tQ)  ®  ri./*  ti),  we  finally  obtain  that 

T;  ([Vi/]ni  ®  n4)  h  [t/y\{ri.f^  =  ti)  ■. 

3x.Ti]  \t/y]{x@k'  Q'{t')  0  ti@/co  Qo(^o)  ®  ^i-fi  — >  0  Hs).  This  is  exactly  what  we 

wanted  to  prove. 

We  have  now  gone  through  all  the  induction  cases  and  we  have  completed  the  proof  of  the 
Substitution  Lemma. 

We  also  need  to  define  the  following  lemma: 

Lemma  2  (Memory  Consistency) 

1.  ^  (5),(F(n),^  ^  R),  p  ok  then  u,  (S.  p(l)  ^  Q) ,  {F {U.) ,  p{l)  ^  R) ,  p  ok, 
where  R  =  x@k  Q. 

2.  If  p,  S,  i^(n),  p  of  and  o  f  dom(p),  then  p'  =  p\o  ^  C(p(;))|.E'  =  (E  ,  o  ^  unpacked) ,  = 

F(n),  p  ok. 

3.  If  p,  (S,  I  -w  Q),  (F(n),  I  ^  R),  p  ok  and  V  f  dom{p)  then  p,  (S,  I'  ^  Q),  (L'(n),  I'  -w 
R),  p[l'  -w  p(;)]  ok,  where  R  =  x@k  Q. 

4.  Ifp,{T,i,T,2),{F{Ili®Il2)),pokand 

unpacked{r@k  Q{ti))  G  IIi,  then  p,  (S2,  r  Qfi)),  {F{Il2),r  r@k  Q{ti)),  p  ok. 

5.  IfpfT,i,T,2),{F{Ili<SiIl2)),pokand 

[t2/x]R2  G  III,  with  predicate  Q2{T  x)  =  R2  E  C,  then 
p,  {T,2,  r  -w  (52(^2)),  (^(112),  r  a;@l  (32(^2)),  P  ok. 

6.  Ifp,{T,o,Tj2),{F{Ilo®Il2)),pokandr@kQ{ti)  G  IIo 
and  predicate  Q{T  x)  =  Ri  E  C  and 

Vr',  X  :  (  unpacked{r'@k'  Q{x))  E  (Ho  0  112)  ^  Hq  0  112  L  r  7^  r')  then  p,  S'  =  (S2,  r  ^ 
unpacked) , 

F(n')  =  (F(n2),  F{[ti/x]Ri  0  r  -w  unpacked{x@k  Q{ti)))), 
p  ok. 

7.  //■/r,  (So,  S2),  (F(no  0  112)),  ppfc  an(ir@A:  (3(L)  e  Hq 

and  predicate  Q{T  x)  =  Ri  E  C 

then  p,  S'  =  (S2,  r  -w  unpacked) , 

F{U')  =  {F{n2),F{[F/x]Ri)), 
p  ok. 
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8.  If  Fill),  p  ok  and  p{pil))  =  C{o)  and  fieldsiC)  =  Tf  then  =  (S,Oi  — )■ 
Q),  F(n')  =  (-F(n),  Oi  R) ,  p  ok^  where  R  =  x@k  Q. 

9.  Ifp,  S  =  (So,  h  ^  Q'id)),  FiU)  =  (F(no),  I2  ^  y@k'  Q'it')  ®  x@ko  QoiR)  ®  R.f  ^ 
x),  p  ok  and  pil^)  =  02,  then 

p'  =  p[pili)  [o2/oi]C(o)],  S'  =  (S,  02  -w  Q'(F)), 

F(n')  =  (F(n),02  y@k'  Q'(F)® 

x@kQ  QoiR)  ®  ti.fi  ^  x),p  ok 
Proof  of  memory  consistency  lemma 

1 .  Environment  map 

Assuming  /r,  (S,  /  -w  Q),(m  ,  /  'w  i?) ,  p  ofc  we  need  to  show  that 

p(0  Q) 5  (-^(n) 5  p(Q  R),  p  ok,  where  R  =  x@k  Q.  Memory  does  not  ehange. 
The  only  object  potentially  affected  is  pf),  which  is  equal  to  0,  say.  Since  props{p,  (S,  I  -w 

Q) i  (^(n),  I  R),P,o)  =  props{p,  (S,  o  Q),  (F(n),  o  R),  p,  o),  we  can  conclude 

that  p,  (S,  pil)  Q),(n,p(/)  R),  p  \~  o  ok,  and  therefore  p,  (S,  o  ^  Q).(m)  ,  o  -w 

R) ,  p  ok. 

2.  New  object 

Assuming  p,  S,  F(n),  pqfc  ando  f  dom{p),  we  have  to  show  that  |u'  =  p[o  ^  C(p(/))],  S'  = 
(S,  o  ^  unpacked),  F(n')  =  F(n),  p  ok.  It  must  be  that  p(/)  =  o'  for  some  objects  o'.  The 
only  objects  affected  are  o,  o'.  Since  p{o')  =  p'(o')  and 

propsip,  S,  F(n),  p,  o')  =  propsip',  S',  F(n'),  p,  o')  we  can  deduce  that 

p',  S',  F(n'),  p  h  o'  ok. 

The  heap  invariants  are  satisfied  and  we  can  deduce  that  p' ,  S',  F(n'),p  h  o  ok.  Thus, 

p',s',F(n'),ppfc. 

3.  Environment  rename 

Assuming  p,  (S,/  ^  Q),  (F(II),/  ^  F),p  ok  and  V  ^  dom-ip),  we  have  to  show  that 
p,{T,,l'  ^  Q),(F(n),/'  ^  F),p[/'  ^  p{l)]  ok,  where  R  =  a:@/c  Q.  The  only  object 
affected  can  be  pil).  By  the  same  argument  above,  that  the  props  sets  are  identical,  we  can 
conclude  that  p,  (S,  I'  -w  Q),  (F(n),  /'  -w  F),  p[l'  p(/)]  ok. 

4.  Pack2 

Assuming  fli  =  [p,  S  =  (Si,S2),F(n)  =  (F(ni  (g)  112)),  p]  ok,  we  have  to  show  that 
fl2  =  [p,  S'  =  (S2,r  ^  (5(fi)),  F(n')  =  (F(n2),r  ^  r@k  Q(fi)),p]  ok.  Let’s  take  an 
arbitrary  o.  Since  p  and  p  don’t  change,  the  only  changes  in  the  obj Props  corresponding 
to  and  to  Q2  come  from  the  different  o  R  extracted  from  IT  and  from  H'.  We  have 
to  show  that  the  heap  invariants  are  preserved  by  the  different  o  -w  F  in  F(n'),  knowing 
that  the  invariants  are  preserved  by  the  different  o  F  in  F(ni  0  112).  Knowing  this,  we 
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deduce  that  the  invariants  cannot  he  broken  by  the  assertions  in  112.  Thus,  we  only  have  to 
see  if  r  -w  x@k  Q{ti)  is  in  contradiction  with  any  assertions  about  r  in  112.  We  also  know 

that  unpacked{r@k  Q{ti))  is  in  Hi. 

Since  Hi  ok,  the  only  object  propositions  in  112  about  r  have  to  be  of  the  form  r@ki  Q{ti) 
such  that  the  sum  of  k  and  the  ki  fractions  is  less  than  1.  II2  could  also  contain  object 
propositions  of  the  form  unpacked{r@ki  QiQ),  but  the  fields  in  the  predicates  are  disjoint, 
according  to  the  heap  invariants.  Thus,  (112,  r  r@k  Q{ti))  satisfies  the  heap  invariants, 
E'  is  compatible  with  ft'  and  the  primitives  are  preserved,  so  p,  E',  ft',  p  ok. 

5.  Packl 

Assuming  Hi  =  [p,  (Ei,  E2),  F(ni  ®  112),  p]  ok,  we  have  to  show  that  H2  =  [/r,  E'  = 
(E2,r  <32(^2)), 

F(n')  =  (F(n2),r  r@l  <32(^2)),  p]  ok, 

where  [f2/T]i?2  G  lli,  with  predicate  Q2{T  x)  =  R2  E  C.  Let’s  take  an  arbitrary 
o.  Since  p  and  p  don’t  change,  the  only  changes  in  the  objProps  corresponding  to  Hi  and 
to  H2  come  from  the  different  o  R  extracted  from  F(ni  0  112)  and  from  (F(n2),  r  -w 
r@l  (32(^2))-  We  have  to  show  that  the  heap  invariants  are  preserved  by  the  different  o  R 
in  (F(n2),r  -w  r@l  (32(^2),  knowing  that  the  invariants  are  preserved  by  the  different 
o  i?  in  F(ni  0  112).  Thus,  we  only  have  to  see  if  r  r@l  (32(^2)  is  in  contradiction 
with  any  assertions  about  r  in  F(n2). 

We  know  that  [t2/x]R2  is  in  11 1  and  that  Hi  ok.  When  the  field  keys  that  are  present  in  R2  are 
packed  to  the  object  proposition  Q2  with  a  fraction  of  1,  these  field  keys  cannot  be  used  in 
any  other  object  propositions.  Knowing  this,  we  deduce  that  the  invariants  cannot  be  broken 
by  the  assertions  in  112.  It  follows  that 

(F(n2),r  -w  r@l  (32(^2))  satisfies  the  heap  invariants.  Since  [t2/x]R2  G  lli  and  the 
primitives  corresponding  to  lli  ®  112  are  ok,  there  can  be  no  primitives  in  112  that  contradict 
[t2/x]R2.  We  know  that  predicate  Q2{T  x)  =  R2  E  C  and  we  can  deduce  that  the 
primitives  corresponding  to  p,  E',  F(n'),  p  are  ok.  Thus  p,  E',  F(n'),  p  ok- 

6.  Unpack2 

Assuming  Hi  =  [p,  E  =  (Eq,  E2),  F(n)  =  F(no  0  II2),  p]  ok,  we  have  to  show  that 
H2  =  [p,  E'  =  (E2,r  ^  unpacked), 

F(n')  =  (F(n2),[F/x]Fi),p]  ok. 

Let’s  take  an  arbitrary  o.  Since  p  and  p  don’t  change,  the  only  changes  in  the  objProps 
corresponding  to  Hi  and  to  H2  come  from  the  different  o  R  extracted  from  F(no  0  112) 
and  from  F(n').  We  have  to  show  that  the  heap  invariants  are  preserved  by  the  different  0  -w 
R  in  F(n'),  knowing  that  the  invariants  are  preserved  by  the  different  o  F  in  F(no  0112). 
Knowing  this,  we  deduce  that  the  invariants  cannot  be  broken  by  the  assertions  in  112.  Thus, 
we  only  have  to  see  if  r  -w  unpacked(r@fc  Q{ti))  and  [ti/x\Ri  are  in  contradiction  with 
any  assertions  about  r  in  F(n2). 
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Since  Vr',  t  :  (  unpacked{r'@k'  Q{t))  G  (Ho  U  112)  ^  Hq,  112  h  r  7^  r')  the  heap  invariants 
allow  us  to  infer  that  112  does  not  contain  any  object  that  is  unpacked  from  the  predicate 
Q  and  aliases  with  r.  We  also  know  that  r@k  Q{ti)  G  llo.  Using  the  heap  invariants, 
we  deduce  that  if  there  is  an  object  proposition  referring  to  r  in  112,  this  object  proposition 
must  be  r@ki  Q{ti)  with  the  sum  of  fractions  being  less  than  1.  II2  might  also  contain 
r@ki  (52(^2)  such  that  the  field  keys  of  Q2  and  Q  are  disjoint. 

The  formula  [ti/x]Ri  corresponds  to  r,  after  it  got  unpacked.  In  this  formula  there  might  be 
object  propositions  referring  to  r  or  to  other  references  that  appear  in  112.  Since  r  was  packed 
to  Q,  using  object  propositions  from  llo,  right  before  being  unpacked  and  since  Qijk)  =  i?i, 
we  deduee  that  [ti/x\Ri  will  only  contain  object  propositions  that  are  already  in  llo.  This 
means  that  the  different  o  R  extracted  from  F(no  ®  112)  are  compatible  with  each  other 
and  with  r  ^  unpacked(r@/i:  Q{ti))  (  same  reasoning  as  in  the  previous  paragraph). 

The  heap  invariants  hold  of  11'  because  there  is  no  object  that  aliases  with  r  that  is  unpacked 
from  Q  in  11',  and  also  because  r  ^  unpacked(r@fc  r@k  Q(ti)  and  [ti/ljk\Ri  do  not 

contain  object  propositions  or  primitives  that  are  not  compatible.  Thus,  p,  E',  F(n'),  p  ok 

7.  Unpack  1 

The  proof  of  this  case  is  very  similar  to  the  proof  of  the  previous  ease  Unpack2. 

8.  Field  read 

Assuming  p,  S,  F(n),  p  ok  and  p{p{l))  =  C(o)  and 

fieldsiC)  =  Tf,  we  have  to  show  that  p,  E'  =  (E,Oi  -w  (5),F(n')  =  (F(n),Oj  -w 
R),p  ok,  where  R  =  x@k  Q.  The  only  objeet  affected  is  o^. 

Beeause  of  the  way  fieldProps{p,  E')  is  dehned,  any  object  proposition  about  o*  will  be  ex¬ 
tracted  from  the  object  propositions  referring  to  p(p(/)),  which  are  already  in  11.  This  means 

that  props{p,  E,  F(n),  p,  Oj)  =  props{p,  E',  F(n'),  p,  o*)  and  p,  E',  F(n'),  p  h  Oj  qk.  Thus 
p,  E',  F(ll'),  p  ok. 

9.  Assignment 

Assuming  p,T.  =  (Eq,  h  Q'it')),  -U(n)  =  (F(no),  k  ^  h^k'  Q\t')),  p  ok  and  pl^k)  = 
02,  we  have  to  prove  that  p'  =  p[p(/i)  [o2/oi]C'(b)],  E'  =  (E,02  ^  Q'(f')),  F(n')  = 

(F(n),  02  02@k'  Q'[t')),p  ok.  The  only  object  that  changes  is  o*. 

Since  props(p,  E,  F(n),  p,  o*)  =  props{p! ,  E',  F(n'),  p,  Oj)  and 

p,  E,  F(n),  p  h  Oi  ok,  we  can  conclude  that 

p',  E',  F(n'),  p\-  Oi  ok  and  thus  p',  E',  F(n'),  p  ok. 

The  proof  for  the  Preservation  Theorem  is  done  by  induction  on  the  dynamic  semantics  rules. 
Proof  of  the  Preservation  Theorem 
Case  (Lookup) 

1.  By  assumption 
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(a)  r,  n  h  /  :  3  X.T]  R 

(b)  /i,  S,F(n),pofc 

(c)  ^  IJ-,P,pil) 

2.  By  inversion  on  la 

(a)  r  =  (Fi,  I  :  T) 

(b)  F(n)  =  (F(ni),  I  R),  where  R  =  x@k  Q 

(c)  E  =  (El  ,  I  -w  Q),  where  Ei  is  the  store  type  corresponding  to  Hi. 

3.  p,  (Fi,  I  :  T),  (F(ni),  /  ^  i?),  (El,  /  ^  Q)  pfc  -by  2 

4.  p{l)  =  o,  for  some  o  -  by  Object  Proposition  Consistency 

5.  (F,o:T),(ni  ,  o  R)  \-  o  :  3x.T]  R  -by  (Term) 

6.  Let  F'  =  (F,  p{l)  :  T),  F(n')  =  (F(ni),  p{l)  ^  R)  and  E'  =  (Ei,  p(0  ^  Q) 

1.  V,  n'  h  p(l)  :  3x.T-  R  -by  6,5 

8.  /i,  (Ei,p(/)  ^  Q),  (F(ni),  p(/)  ^  R),  p  ok  -by  3,4,  memory  consistency  lemma 

9.  p,  E',  F(n'),  p  ok  -by  6,  8 

10.  q.e.d  -by  7,  9 

Case  (New) 

1.  By  assumption 

(a)  F,  n  h  nere  67(1)  :3y.T;F 

(b)  E,F(F[),ppfc 

(c)  p,  p,  new  C(i)  — >■  p' ,  p,  o 

(d)  o  ^  dom{p) 

(e)  p'  =  p[o  67(p(/))] 

2.  By  inversion  on  la 

(a)  3y.T]  R  =  3z.67;  z.f  — >  6  0  IIi 

(b)  F  =  (Fi,FT) 

(c)  fields{C)  =  Tj 

3.  Let  r  =  (F,  0  :  67),  F(n')  =  (F(ni),  o  ^  {oj  ^  i)) 

4.  Let  E'  =  (E,  o  -w  unpacked) 
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5.  r',  n'  h  o  :  Bz.C;  z.f  t  (g)  Hi  -by  (Term) 

6.  ^^[o  ^  ^  unpacked),  (F(ni),  o  -w  (o./  — )>  t)),p  ok  -by  memory  consis¬ 

tency  lemma 

7.  q.e.d.  -by  5,  6 
Case  (Let-o) 

1.  By  assumption 

(a)  r,  n  h  /et  X  =  o  m  62  :  3  W.T2]  R3 

(b)  p,T,,F{Il),pok 

(c)  p,  p,  let  X  =  o  in  62  ^  p,  p[l  o],  [l/x]e2 

(d)  I  ^  dom{p) 

2.  By  inversion  on  la 

(a)  T;  n  h  o  :  Bx.Ti;  Ri  0  112 

(b)  (r,  X  :  Ti);  (112  0  Ri)  3  62  :  3u;.T2;  R3 

3.  r  =  (Ti,  o  :  Ti),  F(n)  =  (F(n2),  o  Ri)  -by  inversion  on  2a 

4.  Also,  S  =  (El,  o  -w  Q]^),  where  Ri  =  x@k  Qi 

5.  Let  r'  =  (r,  /  :  Ti),  F(n')  =  (F(n2),  I  Ri),  E'  =  (E2, 1  Qi)  ,  where  E2  corresponds 
to  112 

6.  (r,  l  :  Ti);  (F(n2),  I  Ri)  L  [//x]e2  :  3w.T2;  [//xjFs  -by  Id,  2b,  Substitution  Lemma 

7.  r',  n'  h  62  :  3  W.T2;  i?3  -by  6 

8.  p,  (E2,  o  -w  Qi),  (F(n2),  o  -w  i?i),  p  pfc  -by  2a 

9.  p,  (E2, 1  ^  Qi),  (F(n2),  I  Ri),  p[l  0]  ok  -by  memory  consistency  lemma 

10.  p,E',F(n'),p[/  ^  0] 

11.  q.e.d.  -by  10,  7 
Case  (Let-e) 

1.  By  assumption 

(a)  r,Il  \-  let  X  =  61  in  62  :  3w.T2',  F3 

(b)  p,  E,F(n),ppfc 

(c)  p,  p,  let  X  =  61  m  62  —7-  p' ,  p',  let  x  =  e!-y  in  62 
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(d)  //,p,ei  ^ 

2.  By  inversion  on  la 

(a)  r,  n  h  ei  :  Bx.Ti;  Ri  ®  112 

(b)  F;  (i?i  ®  112)  h  62  :  3w.T2',  R3 

3.  By  induction  on  lb,  Id,  2a 

(a)  BFo;  n'  such  that  Fq,  H'  h  e'  :  3x.Ti;  Ri 

(b)  3  E'  such  that  E',  F(n'),  p'  ok 

4.  Let  F'  =  F  U  Fo 

5.  F';  n'  h  let  X  =  e'^  in  62  :  3w.T2;  R3  -by  3a,2b,  (Let) 

6.  q.e.d.  -by  3b,5 

Case  (Let-v)  is  very  similar  to  Case  (Let-o)  and  we  have  not  included  it  here. 

Case  (Pack) 

Subcase:  the  static  semantics  rule  corresponding  to  (Pack)  is  (Pack2). 

1.  By  assumption 

(a)  F,  n  h  pack  r@k  Q{ti)  in  ei  :  3x.T ;  R 

(b)  p,  E,F(n),ppfc 

(c)  p,  p,  pack  r@k  Q{ti)  in  Ci  -P-  p,  p,  Ci 

2.  By  inversion  on  (Pack2) 

(a)  F;  n  h  r  :  C*.  [ti/x]i?i0 
unpacked(r@/c  Q{h))  ®  Hi 

(b)  F;  (Hi  0  r@k  Q{h))  h  e  :  3x.T;  R 

(c)  predicate  Q{x)  =  Ri 

(d)  0  <  A:  <  1 

3.  Let  F(n')  =  (F(ni),  r  ^  r@k  Q(F)),  E'  =  (Ei,  r  ^  g(L),  F'  =  F 

4.  F',  n'  h  e  :  3x.T;  R  -by  2b,  3 

5.  p,  (El,  r  Q{ti)),  (F(ni),  r  ^  r@k  Q{ti)),  p  ok  -by  memory  consistency  lemma 

6.  q.e.d.  -by  4,  5 

Subcase:  the  static  semantics  rule  corresponding  to  (Pack)  is  (PackI). 
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1.  By  assumption 

(a)  r,  n  h  pack  r@l  (52(^2)  in  e  :  3x.T ;  R 

(b)  /i,S,F(n),pofc 

(c)  p,  p,pack  r@l  Q2{t2)  in  e  ^  p,  p,  e 

2.  By  inversion  on  (Pack  1) 

(a)  F;  n  h  r  :  C;  [t2/^]^2  ®  Fii 

(b)  F;  (Hi  0  r@l  (52(^2))  1“  e  :  3x.T]R 

3.  Let  F(n')  =  (F(ni),  r  ^  r@l  Q2©),  S'  =  (Si,  r  ^  Q2(^),  T'  =  F 

4.  F',  n'  h  e  :  3x.T;  R  -by  2b,  3 

5.  p,  (Si,  r  ^  (52(^2)),  (-^(ni),  r  ^  r@l  <52(^2))  P  ok  -by  memory  consistency  lemma 

6.  q.e.d.  -by  4,  5 
Case  (Unpack) 

Subcase:  the  static  semantics  rule  corresponding  to  (UNPACK)  is  (Unpack2). 

1.  By  assumption 

(a)  F,  Ft  h  unpack  r@k  Q{ti)  in  e  :  3x.T]  R 

(b)  p,T,,F(n),p  ok 

(c)  p,  p,  unpack  r@k  Q{ti)  in  e  ^  p,  p,e 

2.  By  inversion  on  (Unpack2) 

(a)  F;nhr:C';r@A:g(U)0ni 

(b)  F;  (III  0  [U/^]i?i0 
unpacked(r@A:  Q{h)))  F  e  :  3x.T-,  R 

(c)  Vr',  t  :  (  unpacked{r'@k/  Q(t))  G  FI  ^  Ft  h  r  7^  r') 

(d)  predicate  Q{x)  =  Ri  E  C 

(e)  0  <  A:  <  1 

3.  Let  F(n')  =  (F(n2  0  [i~i/x]Ri), 

T  unpacked(r@A:  Qih))), 

S'  =  (S2,  r  ^  unpacked),  F'  =  F 

4.  F',  n'  h  e  :  3x.T;  R  -by  2b,  3 
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5.  jj,  (E2,  r  unpacked) ,  (F(n2  ® 

r  -w  unpacked(r@fc  Q{ti))),p  ok  -by  memory  consistency  lemma 

6.  q.e.d.  -by  4,  5 

Subcase:  the  static  semantics  rule  corresponding  to  (Unpack)  is  (UnpackI). 

1.  By  assumption 

(a)  r,  n  h  unpack  r@l  Q{ti)  in  e  :  3x.T ;  R 

(b)  /i,  S,F(n),pofc 

(c)  jjL^  p,  unpack  r@l  Q{ti)  in  e  ^  p,  p,  e 

2.  By  inversion  on  (UnpackI) 

(a)  r;nhr  :ri;r@lQ(U)®ni 

(b)  F;  (Hi,  [U/x]/?!)  h  e  :  Bx.T;  i? 

(c)  predicate  Q{x)  =  G  C 

3.  Let  F(n')  =  F(ni  0  [ti/^Ri), 

S'  =  (Si,  r  unpacked),  F'  =  F 

4.  F',  n'  h  e  :  3x.T;  R  -by  2b,  3 

5.  p,  (Si,  r  ^  unpacked) ,  F(ni  0  [ti/x]Ri),  p  ok  -by  memory  consistency  lemma 

6.  q.e.d.  -by  4,  5 
Case  (IF-TRUE) 

1.  By  assumption 

(a)  F,  n  h  if{true){ei}else{e2}  :  3x.T-,R 

(b)  p,  S,  F(Il),  p  ok 

(c)  //,p,i/(true){ei}{e2}  ^  ;u,p,ei 

(d)  3x.T ;  R  =  3x.T ;  i?i  0  i?2 

2.  By  inversion  on  the  static  semantics  rule  (If):  F,  11  h  ei  :  3x.T]  Ri 

3.  Let  F'  =  F,  n'  =  n,  S'  =  S 

4.  Ri  ©  R2  is  true  if  Ri  is  true  or  if  R2  is  true 

5.  F',  n'  h  Cl  :  3x.T ]  Ri®  R2  -by  2,3,4 

6.  p.  S',  F(n'),  p  pfc -by  3,1b 
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7.  q.e.d.  -by  5,6 
Case  (IF-FALSE) 

1.  By  assumption 

(a)  r,  n  h  if(false){ei}else{e2}’-3x.T]R 

(b)  /i,  S,F(n),pofc 

(c)  iJ,,  p,if{false){ei}else{e2}  p,p,  62 

(d)  3x.T ;  R  =  3x.T ;  i?i  0  i?2 

2.  By  inversion  on  the  static  semantics  rule  (If):  F,  II  h  62  :  3x.T;  R2 

3.  Let  F'  =  F,  n'  =  n,  S'  =  S 

4.  Ri  ©  R2  is  true  if  Ri  is  true  or  if  R2  is  true 

5.  F',  IT'  h  62  :  3x.T ;  Ri(B  R2  -by  2,3,4 

6.  u.  S',  F(Il'),  p  ok  -by  3,Ib 

7.  q.e.d.  -by  5,6 
Case  (Field) 

1.  By  assumption 

(a)  F,  n  h  l.f,  :  3x.Tr]  R 

(b)  /i,  S,  F(n),  p  qfc 

(c)  p,p,l.f^  p',p,o, 

(d)  p{p{l))  =  C{o) 

(e)  fteldsiC)  =  Tf 
(0  Tr  =  R 

2.  By  inversion  on  the  static  semantics  rule  (Field) 

(a)  /./j  :  Tr  is  a  field  of  C 

(b)  r;Uh[l.f,/x]R 

3.  Let  F'  =  (F,  o,  :  T,),  F(n')  =  (F(n),  o,  ^  R) 

4.  Let  S'  =  (S,  Oi  ^  Q),  where  R  —  x@k  Q 

5.  F',  If'  h  Oi  :  3x.Ti;  R  -by  (Term) 

6.  p,  S'  =  (S,  Oi  Q),  F(n')  =  (F(n),  Oj  -w  R'jf  p  ok  -by  memory  consistency  lemma 
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7.  q.e.d.  -by  5,6 
Case  (Assign) 

1.  By  assumption 

(a)  r,n  h  {h.f  =  h)  :  3X.T-R 

(b)  u.  S,  n,  p  ok 

(c)  /i,  p,  {li.f  =  I2)  — )■ 

p[p{h)  [p{l2)/oi\C{o)],p,p{l2) 

(d)  pipih))  =  C{o) 

(e)  fields{C)  =  Tf 

2.  By  inversion  on  the  static  semantics  rule  (Assign) 

(a)  F;  n  h  I2  ■  Tp  l2@kQ  Qo{to)  Hi,  thus  T  =  Tj 

(b)  r;Uihh.f  :Tprm'Q'{d)®Il2 

(c)  n2  F  /i./  — )■  r*  0  IIs 

(d)  3x.T;  R  =  3x.Ti;x@k' Q'{t')  IS)  Qo{to)  iSi 

3.  3  02  such  that  ^((2)  =  02. 

4.  Let  r  =  {G,  02  :  7)),  F(n')  =  (F(n  0  l2@ko  QoiR)  0  R.f,  ^  k),  02  ^  Q'{k)), 

S'  =  (S,02^Q'(F)). 

5.  r',  n'  h  02  :  3x.Tj;  R  -by  (Term) 

6.  p,'  =  p[p{li)  ^  [pih) / Oi\C jo)],  S3  FfnQ,  p  ok  -by  memory  consistency  lemma 

7.  q.e.d.  -by  5,  6 
Case  (Invoke) 

(a)  By  assumption 

i.  T,Ii3  li.m{l2) '.3x.T\R' 

ii.  /i,  S,  F(n),  p  qk 

hi.  p,  p,li.m{l2)  — >  p,  p,  [ll/this,  l2/x]e 
iv.  h  PR 

V.  pipih))  =  C(o) 

vi.  method{m,  C)  =  m{x){return  e} 

(b)  By  inversion  on  the  static  semantics  rule  (Call) 

i.  r  h  :  F  and  r  h  I^TT 

ii.  F;  n  h  [(i/t)iis][/2/T]Fi  0  III 
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bindFields{R,  R,  /J.)  =  /\v  binop  v 
h  V  binop  V 

primitiveSok{R,  m) 


primitivesok 


bindFields{Ri,  R,  p)  =  Vi  i  =  1,2 
h  v\  binop  V2 

bindFields{Ri  binop  R2,  R,  p)  =  R'l  binop  R'2 


binopok 


bindFields{Ri,  R,p)  —  Vi  i  =  1,2 

^  Vi  f\  V2 

bindFields{Ri  ©  R2,  R,  p)  =  R'l  ®  R'2 


_ /^b)/]  =  V _ 

bindFields{o.f  x,  R,  p)  =  v 


f  icldok 


IJ^[oJ]=v  f^xER 
bindFields{x,  R,  p)  =  v 


vavok 


Figure  17:  Rules  for  primitives  ok 


iii.  mtypeijn,  (7)  =  Vx  :  T .3result.Tr;  R'l  R 

iv.  Ri  h  R'^ 

V.  3x.T;  R'  =  3  result. Tp,  [li / this\[l2 /x]R 

(c)  From  7(a)iv  we  know  that  the  body  {return  e}  of  the  method  m  implements  its  spec¬ 
ification,  so  the  result  will  be  of  the  type  3x.Tr;R',  given  the  arguments  of  the  right 
type. 

(d)  By  the  substitution  Lemma,  we  know  that  [li/this,  l2/x]e  will  be  of  the  type  Bx.T^;  R'. 
Since  p,  S,  F(Jl),  p  do  not  change,  p,  E,  F(n),  p  ok. 

(e)  q.e.d.,  by  7d,  7(a)iv. 

The  cases  Let- V,  Binop,  And,  Or,  Not  are  trivial  and  they  preserve  soundness.  After  having 
proved  the  Preservation  Theorem,  we  should  prove  the  Progress  Theorem  for  our  soundness  proof 
to  be  complete.  Since  our  system  is  similar  to  Featherweight  Java  and  we  did  not  add  new  features 
to  the  language,  the  Progress  Theorem  automatically  holds.  This  concludes  out  soundness  proof. 

Our  system  inherits  a  Progress  property  from  related  object  calculi  such  as  Featherweith  Java. 
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10  Implementation 

10.1  Verification  of  Range  example  in  Boogie 

The  Boogie  encoding  of  the  queues  of  integers  example  from  section  4  is  given  below.  The  code 
below  is  the  implementation  of  our  methodology  for  the  queues  of  integers  example  and  it  is 
verified  by  Boogie. 

//type  Ref  is  intended  to  represent  object  references 
type  Ref ; 

type  PredicateTypes  ; 

type  FractionType  =  [Ref,  PredicateTypes]  int  ; 
type  UnpackedType  =  [Ref,  PredicateTypes]  bool; 

const  null:  Ref ; 

const  unique  RangeP  :  PredicateTypes  ; 

var  val  :  [Ref]  int  ; 
var  next  :  [ Ref]  Ref ; 
var  frac  :  FractionType  ; 
var  unpacked:  UnpackedType; 

function  Range(this:  Ref,  val  :  [  Ref  ]  int  ,  next  :[  Ref  ]  Ref  , 

frac:  FractionType,  x:int,  y:int)  returns  (bool); 

//  frame  theorem 

axiom  (forall  this:  Ref ,  x:int,  y:int,  val:  [  Ref]  int  , 

vail:  [Ref]int,  next:  [Ref]Ref  ,  frac:  FractionType  :: 

( Range  (next[this]  ,val  ,next  ,frac  ,x,y)  && 

( (  val  1  [  thi  s  ] !  =  val  [  thi  s  ] )  II  (  val  1  [  thi  s  ]==  val  [  thi  s  ] ) )  && 

(forall  r  :  Ref  ::  r!=this  ==>  val  1  [  r  ]==  val  [  r  ] )  ) 

==>  Range  (next[this],vall  , next, frac  ,x,y) 

); 


//these  axioms  are  for  packing  the  Range  predicate 
axiom  (forall  this:Ref,  x:int,  y:int,  val:  [Ref]int, 
next:  [Ref]Ref  ,  frac:  FractionType  :: 

{  Range (this  , val, next, frac  ,x,y)} 

((this  !=  null)  &&  (next[this]  ==  null)  && 
(val[this]  >=  x)  &&  (val[this]  <=  y)  ==> 

Range  (this  ,val  ,next  ,frac  ,x,y) 

)); 

axiom  (forall  this:  Ref ,  x:int,  y:int,  val:  [  Ref]  int  , 
next:  [Ref]Ref,  frac:  FractionType  :: 

{  Range (this  , val, next, frac  ,x,y)} 
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((this  !=  null)  &&  (next[this]  !=  null)  &&  (val[this]  >=  x)  && 
(val[this]  <=  y)  &&  Range  (next[this],val,next,frac  ,x,y) 

==>  Range  (this  ,val  ,next  ,frac  ,x,y)  ) 

); 


axiom  (forall  this:Ref,  x:int,  y:int,  val  :  [Refjint, 
next:  [RefJRef,  frac  :  FractionType  :: 

{  Range (this  , val, next, frac  ,x,y)} 

(  thi  s  ==null  )  ==>  Range  (this  , val, next, frac  ,x,y) 

); 


//this  axiom  is  used  for  unpacking 

axiom  (forall  thisiRef,  x:int,  y:int,  val:  [Refjint, 
next:  [RefJRef,  frac:  FractionType  :: 

{  Range (this  , val, next, frac  ,x,y)} 

(  Range (this  , val, next, frac  ,x,y)  ==> 

(this  !=  null)  &&  (val[this]  >=  x)  &&  (val[this]  <=  y)  && 
Range  (next[this],val  , next, frac  ,x,y)  &&  (frac  [this  ,  RangeP]  >=50) 
) 

); 

//modulo  is  not  implemented  in  Boogie 
//so  its  properties  have  to  be  described 
function  modulo  ( x  :  int  ,  y:int)  returns  (int); 
axiom  (forall  x:int,  y:int  ::  {  modulo  (x  ,  y) } 

((0<=x)  &&(0<y)  ==>  (0<=  modulo(x,y)  )  &&  ( modulo  (x ,  y)<y )  ) 
&& 

((0<=x)  &&(y<0)  ==>  (0<=  modulo(x,y)  )  &&  ( modulo  (x ,  y)<—y )  ) 
&& 

((x<=0)  &&(0<y)  ==>  (— y<=  modulo(x,y)  )  &&  ( modulo  (x  ,  y)  <=0)  ) 
&& 

((x<=0)  &&(y<0)  ==>  (y<=  modulo(x,y)  )  &&  (modulo  (x ,  y)  <=0)  ) 

); 


procedure  addModulol  1  (  this  :  Ref,  x:int) 
modifies  val,  unpacked; 

//need  to  put  this  in  for  modulo 

requires  this!=null; 

requires  val[this]>=0  &&  x>=0; 

//this  could  be  100  here 
requires  frac  [this  ,  RangeP]>=50; 

requires  (forall  r  :  Ref  ::  unpacked[r,  RangeP]==  false  ) ; 
ensures  Range  (this  , val, next, frac  ,0,10); 
ensures  frac  [this  ,  RangeP]>  =  50; 

{ 
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assert  unpacked  [  thi s  ,  RangeP]==  false  ; 
assume  Range ( this  ,val  ,next  ,frac  ,0  ,10); 

assert  (this  !=  null)  &&  (val[this]  >=  0)  &&  (val[this]  <=  10) 
&&  Range  (next[this]  ,val  ,next  ,frac  ,0,10)  ; 

unpacked [ thi s  ,  RangeP ] : = true  ; 

val[this]  :=  modulo  ((  val  [  thi  s  ]  +  x  ),  1  1 ) ; 
assert  ( this  !=  null ) ; 

assert  (val[this]  >=  0)  &&  (val[this]  <=  10); 
assert  Range (next[this]  ,val  ,next  ,frac  ,0,10); 
unpacked  [  thi  s  ,  RangeP  ]:=  f  al  s  e  ; 

if  (next[this]  !=  null  ) 

{ 

call  addModulol  1  (  next  [  thi  s  ]  ,  x); 

} 

assert  Range( next [ this ] ,  val,  next , frac  ,  0,  10); 

//val[this]  was  not  modified 
assume  old(val[this])  =  =val[this  ]; 


10.2  Verification  of  Composite  pattern  in  Boogie 

The  Boogie  encoding  of  our  instance  of  the  composite  pattern  from  section  8  is  given  helow.  The 
code  helow  is  the  implementation  of  our  methodology  for  the  composite  example  and  it  is  verified 
by  Boogie. 

//type  Ref  represents  object  references 
type  Ref ; 

type  PredicateTypes  ; 

type  FractionType  =  [Ref,  PredicateTypes]  int  ; 
type  UnpackedType  =  [Ref,  PredicateTypes]  bool; 

const  null  :  Ref ; 

const  unique  leftP  :  PredicateTypes; 
const  unique  rightP  :  PredicateTypes  ; 
const  unique  parentP  :  PredicateTypes; 
const  unique  countP  :  PredicateTypes; 

var  left:  [  Ref]  Ref  ; 

var  right:  [Ref]Ref; 

var  parent:  [Ref]Ref; 

var  count:  [Ref]  int; 

var  unpacked:  UnpackedType; 

var  frac  :  FractionType  ; 
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//axiom  that  shows  there  are  no  cycles  in  the  tree  ,  locally 

//this  axiom  describes  the  data  structure  ,  does  not  depend  on  whether 

//a  predicate  holds  or  not 

axiom  (forall  this:  Ref,  1  :  Ref ,  left:  [Ref]Ref, 
right:  [RefJRef,  parent  :[  Ref  ]  Ref  :  : 

( thi s != right [ thi s ] )  &&  ( thi s ! = 1 e f t [ t h i s ] )  &&  ( thi s  !  =  parent [ thi s  ])) ; 

//axiom  stating  that  this  is  a  binary  tree 

axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [Ref]Ref,  p  arent  :  [  Ref  ]  Ref 
(this!=null)  &&  (  parent  [  th  i  s  ]!=  null  )  ==> 

(( thi s == ri ght [ p arent [ thi s  ]] )  II  ( thi s == 1 e f t [ parent [ thi s  ]]) ) 

); 


function  leftPred  (  thi  s  :  Ref,  left:  [RefJRef,  right:  [Ref]Ref, 

count:  [Ref]int,  frac  :  FractionType  ,  Ic  :  int)  returns  (bool); 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType,  Ic  :  int:: 

((  (left  [  this  ]  !=  null )  && 

countPred(left[this],left,  right,  count,  frac,  Ic)  && 

(  fr  ac  [  1  e  f  t  [  t  h  i  s  ]  ,  countP]  >=  50)  ) 

==>  (leftPred(this,  left,  right,  count,  frac,  Ic)  )  ) 

&& 

(  (  (left[this]  ==  null)  && 

(lc==0)  ) 

==>  (leftPred(this,  left,  right,  count,  frac,  0)  )  ) 

); 


//this  axiom  is  for  unpacking  of  left  predicate  when  left  [this  ]!=  null 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType,  Ic  :  int:: 

(  (  leftPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  Ic)  && 

(left[thisj  !=  null)  )==> 

(  countPred(left[thisJ,left,  right,  count,  frac,  Ic)  && 

( frac [ 1 e f t [ thi s J ,  countPJ  >=  50)  )  )  )  ; 

//this  axiom  is  for  unpacking  of  left  predicate  when  left  [this  J==  null 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType:: 

{  leftPred  ( this  ,  left  ,  right  ,  count,  frac  ,  0)} 

( leftPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  0) 

==>  (left[thisj  ==  null)  )  ); 

function  rightPred  (  this  :  Ref,  left:  [RefJRef,  right:  [RefJRef, 
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count:  [Ref]int,  frac  :  FractionType  ,  rc  :  int)  returns  (bool); 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Ref]  int,  frac:  FractionType,  rc  :  int:: 

((  (right[this]  !=  null)  && 

countPred(right[this],left  ,  right  ,  count,  frac  ,  rc)  && 

(  frac  [  ri  ght  [  thi  s  ]  ,  countP]  >=  50)  ) 

==>  rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  rc)  ) 

&& 

((  (right[this]  ==  null)  && 

(rc==0)  ) 

==>  rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  0)  ) 


//this  axiom  is  for  unpacking  of  right  predicate  when  right  [  this  ]!=  null 
axiom  (forall  this:  Ref,  left:  [RefjRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType,  rc  :  int:: 

(  rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  rc  )  && 

(right[this]  !=  null)  ==> 

(countPred(right[this],left,  right,  count,  frac,  rc)  && 

( frac [ right [ thi s ] ,  countP]  >=  50)  ))); 

//this  axiom  is  for  unpacking  of  right  predicate  when  right  [  this  ]==  null 
axiom  (forall  this:  Ref,  left:  [RefjRef,  right:  [RefjRef, 
count:  [Ref]  int,  frac:  FractionType:: 

( rightPred  ( this  ,  left  ,  right  ,  count,  frac  ,  0) 

==>  (right[thisj  ==  null)  )  ); 

function  countPred  (  thi  s  :  Ref,  left:  [RefjRef,  right:  [RefjRef, 

count:  [Refjint,  frac:  FractionType,  c:  int)  returns  (bool); 
axiom  (forall  this:  Ref,  left:  [RefjRef,  right:  [RefjRef, 
count:  [Refjint,  frac:  FractionType,  c:int  :: 

(  (  (  this  !  =  null )  &&  ( 
exists  Ic:  int,  rc:int  :: 

( leftPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  Ic)  && 

(  frac  [  this  ,  leftP  j  >=  50)  && 

rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  rc )  && 

(frac[this  ,  rightPj  >=  50)  && 

(count[this]  ==  lc  +  rc  +  1)  && 

(  count [this  j==  c )  ) 

)  )  ==>  countPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c)  ) 

); 


//this  axiom  is  used  for  unpacking  of  count  predicate 
axiom  (forall  this:  Ref,  left:  [RefjRef,  right:  [RefjRef, 
count:  [Refjint,  frac:  FractionType,  c:int  :: 
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(  countPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c)  ==> 
(  (this!=null)  && 

(exists  Ic:  int,  rc:int  :: 

(leftPred(this,  left,  right,  count,  frac,  Ic)  && 
(frac[this,  leftP]  >=  50)  && 

rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  rc  )  && 
(frac[this,  rightP]  >=  50)  && 

(count[this]  ==  lc  +  rc  +  1)  && 

( count [ this ]==  c  )) 

)  )  ) 

); 


axiom  (forall  thi  s  :  Ref  ,  count  :  [Refjint  :: 

(this==null)  ==>  (  count  [  thi  s  ]  =  =  0)  ); 

function  parentPred  (  thi  s  :  Ref,  left:  [RefJRef,  right:  [RefJRef,  parent:  [Ref]Ref, 
count:  [Refjint,  frac:  FractionType )  returns  (bool); 
axiom  (  forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef,  parent:  [RefJRef, 
count:  [Refjint,  frac:  FractionType  :: 

( 

( parent [ thi s J  !=  this) 

&& 

countPred(this,  left,  right,  count,  frac,  count[thisJ) 

&& 

(frac[this  ,  countPJ>=50) 

&& 

(  parent  [  this  J  !=  null) 

&& 

parentPred(parent[thisJ,  left,  right,  parent,  count,  frac) 

&& 

( 

(leftPred(parent[thisJ,  left,  right,  count,  frac,  count[thisJ)  && 
(frac[parent[thisj,  leftPJ  >=  50)) 

I  I 

(rightPred(parent[thisJ,  left,  right,  count,  frac,  count[thisJ)  && 

(  frac  [  parent  [  this  J  ,  rightPJ  >=  50)) 

) 

) 

==> 

parentPred(this,  left,  right,  parent,  count,  frac) 

); 


axiom  (  forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef,  parent:  [RefJRef, 
count:  [Refjint,  frac:  FractionType  :: 

( 
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( parent [ this ]  !=  this) 

&& 

countPred(this,  left,  right,  count,  frac,  count[this]) 
&& 

(frac  [this  ,  countP  ]  >=  1 00) 

&& 

(parent[this]==null) 

) 

==> 

parentPred  ( this  ,  left  ,  right  ,  parent  ,  count,  frac) 

); 


//this  axiom  is  used  for  unpacking  of  parentPred 

axiom  (  forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef,  parent:  [RefJRef, 
count:  [Refjint,  frac:  FractionType  :: 

{  parentPred  ( this  ,  left  ,  right  ,  parent  ,  count  ,  frac)} 

(  parentPred  ( this  ,  left  ,  right  ,  parent  ,  count  ,  frac)  ==> 

(  ( parent [ thi s ]  !=  this) 

&& 

(  exists  c : int  :  : 

((  countPred  ( this  ,  left  ,  right  ,  count,  frac  ,  c) 

&& 

(frac  [this  ,  countP]>=50) 

&& 

(( parent [ this ]  !=  null)  ==> 

(parentPred(parent[this],  left,  right,  parent,  count,  frac) 

&& 

((leftPred(parent[this],  left,  right,  count,  frac,  c)  && 
(frac[parent[this],  leftP]  >=  50)) 

I  I 

(rightPred(parent[this],  left,  right,  count,  frac,  c)  && 
(frac[parent[this],  rightP]  >=  50)) 

)  )  ) 

&& 

((  parent  [  this  ]==  null )  ==> 
countPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c)  && 

(frac[this  ,  countP  ]  >=50)  )  )  )) 

)  )  ); 

//axioms  about  the  existance  of  a  variable  and  instantiation 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType:: 

(exists  lc:int  ::  leftPred(this,  left,  right,  count,  frac,  Ic) 

==>  leftPred(this,  left,  right,  count,  frac,  count[left[this]])) 
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axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac  :  FractionType  :  : 

(exists  rc:int  ::  rightPred(this,  left,  right,  count,  frac,  re) 

==>  rightPred(this,  left,  right,  count,  frac,  count[right[this]])) 

); 


axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 
count:  [Refjint,  frac:  FractionType:: 

(exists  c:int  ::  countPred(this,  left,  right,  count,  frac,  c) 
(countPred(this,  left,  right,  count,  frac,  count[this]))  ) 

); 


//frame  axiom  for  count  and  leftPred 

axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 

count:  [Refjint,  countl  :  [Refjint,  frac:  FractionType,  Ic  :  int:: 
(  leftPred  ( this  ,  left  ,  right  ,  count,  frac  ,  Ic)  && 

(forall  r  :  Ref  :  :  r!=this  ==>  count  [  r  J==  count  1  [  r  J ) 

==>  leftPred  ( this  ,  left  ,  right  ,  countl  ,  frac  ,  Ic)) 

); 


//frame  axiom  for  when  frac  is  modified,  for  leftPred 
axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef, 

count:  [Refjint,  frac:  FractionType,  fracl:  FractionType,  lc:int:: 
(  leftPred  ( this  ,  left  ,  right  ,  count,  frac  ,  Ic)  && 

(forall  r  :  Ref  :  :  r!=this==>  (  frac  1  [r  ,  countPJ==  frac  [r  ,  countP  J )  ) 

==>  (leftPred(this,  left,  right,  count,  fracl,  Ic))) 

); 


//frame  axiom  for  countPred 

axiom  (forall  this:  Ref,  left:  [RefJRef,  right:  [RefJRef,  parent:  [RefJRef, 
count  :  [  Ref  J  int  ,  1  e  f  1 1  :  [  Ref  J  Ref  ,  frac:  FractionType,  c:  int:: 

(  countPred  ( thi s  ,  left  ,  right  ,  count  ,  frac  ,  c)  && 

(leftl  [parent[thisJJ==this) 

==>  countPred  ( this  ,  leftl  ,  right  ,  count  ,  frac  ,  c)) 

); 


procedure  Composite  ( this  :  Ref) 

modifies  left  ,  right  ,  parent  ,  count  ,  frac  ,  unpacked; 
requires  this  !=  null; 

ensures  parentPred ( this  ,  left  ,  right  ,  parent  ,  count ,  frac ); 
ensures  leftPred  ( this  ,  left  ,  right  ,  count,  frac  ,  0); 
ensures  rightPred  ( this  ,  left  ,  right  ,  count,  frac  ,  0); 
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ensures  (frac[this  ,  parent?]  >=  50)  && 

(  frac  [  this  ,  left?  ]  >=  50)  && 

(frac[this,  right?]  >=  50)  ; 
ensures  unpacked [ this  ,  parent? ]== f al s e ; 

{ 

count [this]  : =  1  ; 
left[this]  :=  null; 
right  [  this  ]  :=  null  ; 
parent  [  this  ]  :=  null  ; 

assert  left?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0); 

frac[this  ,  left?]  :=  100; 

assert  right?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0); 

frac[this  ,  right?]  :  =  100; 

assert  left?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0)  && 

right?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0)  ; 

assert  count?red ( thi s  ,  left  ,  right  ,  count,  frac  ,  1); 

frac  [this  ,  count?]  :=  100; 

assert  left?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0)  && 

right?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0)  ; 

assert  count?red ( thi s  ,  left  ,  right  ,  count,  frac  ,  1); 

assert  parent?red ( this  ,  left  ,  right  ,  parent  ,  count ,  frac ); 

frac[this  ,  parent?]  :=  100; 

assert  left?red  ( this  ,  left  ,  right  ,  count,  frac  ,  0)  && 

right?red  ( this  ,  left  ,  right  ,  count  ,  frac  ,  0)  ; 
assert  count?red ( this  ,  left  ,  right  ,  count,  frac  ,  1); 

assert  parent?red  ( this  ,  left  ,  right  ,  parent  ,  count  ,  frac  ); 

unpacked [ this  ,  parent? ]:= false ; 

} 

procedure  updateCountRec  ( thi s  :  Ref) 
modifies  count,  frac,  unpacked; 
requires  this!=null; 
requires  unpacked  [  thi  s  ,  parent?]; 
requires  p arent  [  thi s  ]!  =  null 

==>  (  frac  [  parent  [  thi  s  ]  ,  parent?]>0); 
requires  (  parent  [  thi s  ]!=  null )  && 

(this==right[parent[this  ]]) 

==>  (  frac  [  parent  [  thi  s  ]  ,  right?  ]  >  =  50); 
requires  (  parent  [  th i  s  ]!=  nul  1 )  && 

(this == left [parent[this ]]) 

==>  (  frac  [  parent  [  thi  s  ]  ,  left?]>  =  50); 
requires  parent  [  this  ]==  null 

==>  (frac  [this  ,  count?]  >=  50); 
requires  (  forall  r  :  Ref  :  :  (r!=this) 

==>  (unpacked[r,  count? ]== f al s e  )) ; 
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requires  unpacked [ thi s  ,  leftP ]==  false  ; 
requires  unpacked [ thi s  ,  right? ]==  false  ; 
requires  (frac[this  ,leftP]  >=50)  && 

(  frac  [  this  ,  right?  ]  >=50); 
requires  (frac[this  ,  count?]  >=  50); 

ensures  ( parentPred ( this  ,  left  ,  right  ,  parent  ,  count ,  frac )  ); 
ensures  unpacked [ this  ,  parent? ]== f al s e ; 

{ 

var  fracLocal  :  FractionType  ; 

assume  (exists  cl  :  int  :: 

left?red(this,  left,  right,  count,  frac,  cl)); 
assume  (exists  c2:int  :: 

rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c2)); 

if  (  parent  [  this  ]  !=  null) 

{ 

//we  assert  what  is  true  when  unpacked  [  thi  s  ,  parent?] 

assert  frac[this,  count?]>=50; 

fracLocal  [  this  ,  count?  ]:=  frac  [  this  ,  count?]; 

//this  asserts  that  we  have  a  fraction  to  parent? 
assert  (  frac  [  parent  [  thi  s  ]  ,  parent?]>0); 

//we  unpack  parent  [this]  from  parent? 
unpacked  [parent[this],  parent?]:=true; 
assert  (forall  r :  Ref : :  (r!=this)  ==> 

(unpacked[r,  count?]== false  )) ; 

//we  can  assume  this  because  we  just  unpacked 

// parent  [  thi s  ]  from  parent? 

assume  frac  [  parent  [  thi  s  ]  ,  count?]>  =  50; 

fracLocal  [  parent  [  thi  s  ]  ,  count?  ]:=  frac  [  parent  [  thi  s  ]  ,  count?]; 

//we  unpack  parent  [this]  from  count? 
unpacked[parent[this]  ,  count?  ]:=true; 

//we  can  assume  this  because  we  just  unpacked  parent  [this]  from  count? 
assume  (frac[this  ,left?]>=50)  &&  (frac[this  ,  right?  ]  >  =  50); 
fracLocal  [  parent  [  thi  s  ]  ,  r  ight?  ]:=  frac  [  parent  [  th  i  s  ]  ,  right?]; 


//we  assume  this  is  the  right  child  of  parent[this] 
//the  other  case  is  analogous 
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assume  this==right[parent[this  ]]; 
assert  (  parent  [  thi  s  ]!=  null  )  && 

( this == right [parent [ this ]]) 

==>  frac  [parent[  this  ]  ,rightP]>  =  50; 
fracLocal  [parent  [  this  ]  ,  rightP  ]:  =  fracLocal  [  parent  [  this  ]  ,  rightP  ] 

+  frac [ parent [ thi s ], rightP  ] ; 

assert  (fracLocal[parent[this  ]  ,rightP]>=100); 

//unpack  parent[this]  from  rightP 
unpacked[parent[this]  ,  rightP]:=true; 
assert  unpacked [ parent [ this ] , rightP ] 

==>  frac [ right [ parent [ this ]] , countP] >=50; 
fracLocal  [  this  ,  countP  ]:=  fracLocal  [  this  ,  countP  ]+ frac  [  this  ,  countP  ]  ; 

assert  (frac[this  ,leftP]  >=50)  &&  (frac[this  , rightP]  >=50); 

assert  unpacked [ thi s  ,  parentP  ] ; 

frac[this  ,  countP  ]:  =  fracLocal  [  this  ,  countP]; 

assert  (frac  [this  ,  countP]  >=  100); 

assert  leftPred(this,  left,  right,  count,  frac,  count[left[this]]); 
assert  (exists  cl:int  ::  leftPred(this,  left,  right,  count,  frac,  cl)); 
unpacked [ this  ,  le f tP  ] : =  f  al s e  ; 

assert  rightPred(this,  left,  right,  count,  frac,  count[right[this]]); 
assert  (exists  c2:int  ::  rightPred(this,  left,  right,  count,  frac,  c2)) 
unpacked [ thi s  ,  r ightP  ] : =  f al s e  ; 

call  updateCount  (  this  ) ; 
assert(  exists  c:int 

countPred  ( this  ,  left  ,  right  ,  count,  frac  ,  c) 

); 

assert  countPred(this,  left,  right,  count,  frac,  count[this]); 
assert  unpacked [ thi s  ,  countP ]== f al s e ; 
assert  (frac [this  ,  countP ]>= 1 00)  ; 

//assert  the  preconditions  of  updateCountRec 
assert  parent [ thi s ]!=  null ; 
unpacked[parent  [  this  ]  ,  parentP]:  =  true  ; 

//we  can  assume  these  because  we  have  just 
//unpacked  parent  [this]  from  parentP 
assume  parent  [parent  [  this  ]]  !  =  null 

==>  (  frac  [  parent  [  parent  [  thi  s  ]]  ,  parentP]>0); 
assume  parent  [  parent  [  this  ]]  =  =  null 

==>  (  frac  [  parent  [  thi s  ]  ,  countP]  >=  50); 
assume  (  parent  [  parent  [  thi s  ]]!=  null )  && 

(this  ==  right  [parent[parent[this  ]]]) 

==>  (  frac  [  parent  [  parent  [  thi s  ]]  ,  rightP  ]  >  =  50) ; 
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assume  (  parent  [  parent  [  thi s  ]]!=  null )  && 

(this == left [parent[parent[this  ]]]) 

==>  (  frac  [  parent  [  parent  [  thi  s  ]]  ,  leftP]>  =  50); 

assert  rightPred(parent[this],  left,  right,  count,  frac,  count[this]); 
assert  (exists  c2;int  ::  rightPred(parent[this],  left,  right,  count,  frac,  c2)) 
unpacked[parent[this  ]  ,rightP]:=false  ; 
assert  (forall  r  :  Ref :  :  ( r  !  =  parent [ thi s ] ) 

==>  (unpacked[r,  countP]== false  )) ; 

//assertions  for  proving  lef  tPred  (  parent  [  thi  s  ]..  . 

//we  assume  this  ,  the  other  case  is  trivial 
assume  left  [  parent  [  this  ]  ]  !=  null; 

assert  unpacked [ 1 e f t [ parent [ thi s ]] ,  countP]== false ; 

//we  can  assume  this  because 

//countPred  is  packed  for  left [ parent [ this ] ] 
assume  countPred(  left  [parent  [  this  ]]  ,  left  , 

right,  count,  frac,  count[this]); 

assert  leftPred(parent[this],  left,  right,  count, 
frac  ,  count[left [parent[this ]]]); 
assert  (exists  cl : int  :: 

leftPred(parent[this],  left,  right,  count,  frac,  cl)); 
unpacked[parent [ this ] , leftP  ]:  =  false  ; 

call  updateCountRec  (parent[this  ]); 
assert  parentPred(parent[this],  left,  right,  parent,  count,  frac); 
assert  unpacked [ parent [ this ] ,  parentP ]== f al s e ; 

//this  is  the  final  assertion  needed 

assert  parentPred ( this  ,  left  ,  right  ,  parent  ,  count ,  frac ); 
unpacked [ thi s  ,  parentP  ]:=  false ; 

} 

else 

{ 

assert  (frac[this  ,  countP]  >=  50); 
fracLocal  [  this  ,  countP  ]:=  frac  [  this  ,  countP  ]  ; 
assert  parent  [  thi  s  ]==  null  ==>  (frac[this  ,  countP]  >=  50); 
fracLocal  [  this  ,  countP  ]:=  fracLocal  [  this  ,  countP]  +  frac[this  ,  countP]; 
frac[this  ,  countP  ]:  =  fracLocal  [  this  ,  countP]; 
assert  (frac[this  ,  countP]  >=  100); 
call  updateCount  (  this  ) ; 

assert  parentPred ( this  ,  left  ,  right  ,  parent  ,  count ,  frac  ); 
unpacked [ this  ,  parentP  ]:=  f al s e ; 

} 

} 
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procedure  updateCount  (  thi  s  :  Ref) 
modifies  count,  frac  ,  unpacked; 
requires  this  !=  null; 
requires  unpacked [ thi s  ,  leftP ]==  false  ; 
requires  unpacked [ thi s  ,  rightP ]==  false  ; 
requires  (frac[this  ,leftP]  >=50)  && 

(frac[this  ,rightP]  >=50)  && 

(frac  [this  ,  countP]  >=  100); 

ensures  (  exists  c:int  :: 

countPred  ( thi  s  ,  left  ,  right  ,  count,  frac  ,  c) 

); 

ensures  unpacked [ thi s  ,  countP]== false ; 
ensures  (frac[this  ,  countP  ]  >  =  1 00) ; 
ensures  (forall  r  :  Ref :  :  (r!=this) 

==>  (unpacked[r,  countP ]== old ( unpacked [ r ,  countP]))); 

{ 

var  newc : int  ; 
newc  :=  1; 

//we  can  assume  this  because  leftP  and  rightP  are  packed 

assume  (exists  cl:int  ::  leftPred(this,  left,  right,  count,  frac,  cl)); 

assume  (exists  c2:int  ::  rightPred(this,  left,  right,  count,  frac,  c2)) 

assert  leftPred(this,  left,  right,  count,  frac,  count[left[this]]); 
assert  rightPred(this,  left,  right,  count,  frac,  count[right[this]]); 

if  (left[this]  !=  null) 

{ 

newc  :=  newc  +  count [ 1 e f t [ thi s  ]]  ; 

} 

if  (right[this]  !=  null) 

{ 

newc  :=  newc  +  count [ right [ thi s  ]] ; 

} 

count[this]  :=  newc; 

assert  leftPred  ( this  ,  left  ,  right  ,  count , 
frac,  count [ left [ this  ]]) ; 
assert  rightPred  ( this  ,  left  ,  right  ,  count, 
frac,  count  [  right  [  this  ]]) ; 

assert  ( newc==l  +  count [ 1 e f t [ th i s ] ]  +  count [ right [ this  ]]) ; 
assert  ( count [ this ]==l  +  count  [ left [ this ]]+  count [ ri ght [ thi s  ]]) ; 
assert  (frac[this,  leftP]  >=  50)  ; 
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assert  (frac[this,  rightP]  >=  50); 
assert  count [ thi s ]==newc  ; 
assert  this!=null; 

assert  countPred(this,left,  right,  count,  frac,  newc ) ; 
unpacked [ this  ,  countP ] : = f al s e ; 

} 


procedure  setLeft  (  this  :  Ref,  l:Ref) 

modifies  parent  ,  left  ,  count  ,  frac  ,  unpacked; 

requires  this!=null; 

requires  this != 1  ; 

requires  1  !=  null  ; 

requires  unpacked [ this  ,  parentP ]== f al s e ; 
requires  unpacked[l,  parentP]== false ; 

requires  (forall  r  :  Ref  :  :  (unpacked[r,  countP  ]==  f  al  s  e  ) ) ; 
ensures  parentPred ( this  ,  left  ,  right  ,  parent  ,  count ,  frac ); 

{ 

//we  can  assume  these  becase  parentPred  is  true  for  this  and  1 
assume  parentPred  ( this  ,  left,  right,  parent,  count,  frac); 
assume  parentPred(l,left,  right,  parent,  count,  frac); 

unpacked [ thi s  ,  parentP ]:= true  ; 

//we  can  assume  the  following  because  we  have 
//just  unpacked  this  from  parentP 
assume  parent  [  thi  s  ]!=  null 

==>  (  frac  [  parent  [  thi  s  ]  ,  parentP]>0); 
assume  (  parent  [  thi s  ]!=  null )  && 

( this == right [parent [ this ]]) 

==>  (  frac  [  parent  [  thi  s  ]  ,  rightP  ]  >  =  50); 
assume  (  parent  [  thi s  ]!=  null )  && 

(this == left [parent[this ]]) 

==>  (  frac  [  parent  [  thi  s  ]  ,  leftP]>  =  50); 
assume  parent  [  thi  s  ]==  null 

==>  (frac  [this  ,  countP]  >=  50); 

assert  (exists  c:  int  :: 

rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c)  ); 
assert  rightPred  ( this  ,  left  ,  right  ,  count, 
frac,  count[right[this]])  ; 
assert  ( exists  c :  int  : : 

countPred(l,  left  ,  right  ,  count,  frac  ,  c)  ); 
assert  countPred(l,  left,  right,  count,  frac,  count[l]); 

parent [ 1 ] : =  thi s  ; 
left[this]:=l; 
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assert  this==parent[l]; 

//proving  the  assertions  for  updateCountRec 

assert  this!=null; 

assert  unpacked  [  this  ,  parentP]; 

assert  left[this]  !=  null; 
assert  countPred(left[this],  left,  right, 
count,  frac  ,  count [ 1 e f t [ thi  s  ]]) ; 
assert  frac [ left [ this ] ,  countP]  >=  50; 
assert  leftPred  ( this  ,  left  ,  right  ,  count , 
frac  ,  count[left[this  ]]); 
unpacked [ thi s  ,  1  e f t P  ] : =  f  al  s e  ; 

assert  rightPred  ( this  ,  left  ,  right  ,  count, 
frac,  count  [  right  [  this  ]] )  ; 

assert  (exists  c2:int  :: 

rightPred  ( this  ,  left  ,  right  ,  count  ,  frac  ,  c2)); 
unpacked [ thi s  ,  righ tP ] : = f al s e ; 

assert  (frac[this  ,leftP]  >=50)  && 

(frac[this  ,rightP]  >  =  50); 
assert  (frac  [this  ,  countP]  >=  50); 
unpacked [ thi s  ,  countP ]:= true ; 
assert  (forall  r  :  Ref  :  :  (r!=this) 

==>  (unpacked[r,  countP]== false  )) ; 

assert  this  !=  null  ; 

assert  unpacked [ thi s  ,  parentP]; 

call  updateCountRec  ( thi s  ) ; 


} 

} 

10.3  Manual  verification  of  Composite  pattern 

Below  we  display  the  manual  verification  of  our  instance  of  the  composite  pattern,  using  the  object 
propositions  methodology. 

class  Composite  { 

private  Composite  left  ,  right  ,  parent; 
private  int  count  ; 

public  Composite 
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^  this®  I  parentO  ®  this@|  left(null,  0)  ®  this@|  right(null,  0) 

{ 

this. count  =  1 ; 

{ this.count  ^  1  } 

this  .left  =  null  ; 

{ this. left  null  ®  this.count  ^  1  } 
this  .  right  =  null  ; 

{ this. right  ^  null  ®  this. left  null  0  this.count  ^  1  } 

this,  parent  =  null  ; 

{ this. parent  ^  null  ®  this. right  null  0  this. left  null  ® 

this.count  ^  1  } 

packthis@1  right(null,  0) 

{ this. parent  null  ®  this. left  ^  null  ®  this.count  1  ® 
this@l  right(null,  0)  } 

pack  this@l  left(null,  0) 

{ this. parent  null  ®  this.count  ^  1  0 
this@l  right(null,  0)  0  this@l  left(null,  0)  } 
split  1  into  two  halts  for  left,  right 
packthis(3)1  count(O) 

{ this. parent  null  0 

this®^  right(null,  0)  0  this®^  left(null,  0)  0  this®l  eount(O)  } 
split  1  into  two  halts  for  count 
packthis(5)1  parentQ 

{  this®^  right(null,  0)  0  this®^  left(null,  0)  0  this®l  parent()  } 

split  1  into  halts 

{  this®  I  right(null,  0)  0  this®^  left(null,  0)  0 
this®^  parentO  ®  this®^  parent()  } 

we  only  need  one  half  of  parent  in  the  post-condition 

{  this®^  right(null,  0)  0  this®^  left(null,  0)  0  this®^  parent()  } 

{QED} 

} 

private  void  updateCountRec  () 

3  kl,  opp,  Icc,  k,  ol,  Ic,  or,  rc. 

(unpacked(this®  kl  parentO)  0 
this. parent  opp  0  opp  ^  this  0 
^(opp  ^  null  — o  opp@k  parentO  ® 

(opp®  I  left(this,  Icc)  ©  opp®  I  right(this,  Icc)))  © 

(opp  =  null  ^  this®  I  count(lcc))  j  0 

unpacked(this®^  count(lcc))  0 
this®  I  left(ol,  Ic)  0  this®  I  right(or,  rc) 
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^  3  kl.this@fcl  parentO) 

{ 

if  (this. parent  !=  null) 

{  3  kl,lcc,opp,  k. 
unpacked(this@kl  parent())  0 
this. parent  ^  opp  0  opp  7^  this  0 
opp@k  parentO  0 

(opp@^  left(this,  Icc)  ©  opp@^  right(this,  Icc))  0 

unpacked(this@^  count(lcc))  0 
3  ol,  Ic,  or,  rc.  0 

this@^  left(ol,  Ic)  0  this@^  right(or,  rc)  } 


split  the  fraction  k  of  opp  in  parent  and  unpack  opp  from  parentQ 
{  3  kl, Icc, opp,  k. 
unpacked(this@kl  parent())  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked(opp@|  parent())  0  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  7^  oppp  0  opp@^ 
count(lccc)  0 

^(oppp  7^  null  ^  oppp @kk  parent!)  0  (oppp@|  left(opp,  Iccc)  ©  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 

(opp@|  left(this,  Icc)  ©  opp@|  right(this,  Icc))  0 
0  opp@|  parent!)  ® 

unpacked(this@^  count(lcc))  0 
3  ol,  Ic,  or  rc.  0 

this@^  left(ol,  Ic)  0  this@^  right(or,  rc) 


unpack  opp  from  ^  count(lccc) 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parent!))  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked!opp@|  parent!))  ®  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  7^  oppp  0 

unpacked!opp@|  count!lccc))  0  3  oil,  orr,  11c,  rrc.  0  opp@|  left!oll,  11c)  0  opp@|  right!orr, 
rrc)  0 
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^(oppp  7^  null  ^  oppp@kk parentO  (g)  (oppp@|  left(opp,  Iccc)  ©  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  © 

(opp@|  left(this,  Icc)  ©  opp@^  right(this,  Icc))  © 

©  opp@  I  parentO  © 

unpacked(this@^  count(lcc))  © 

3  ol,  Ic,  or,  rc. 
this. count  ^  Icc  © 

Icc  =  Ic  +  rc  +  1  © 

this@^  right(or,  rc)  ©this@^  left(ol,  Ic)  } 


this  is  either  the  right  or  left  child  of  opp.  We  analyze  both  cases. 

1  .In  the  first  case  we  assume  it’s  the  right  child, 
instantiate  orr  =  this,  rrc  =  Icc;  merge  both  |  to  opp  in  right 
{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentQ)  © 
this. parent  ^  opp  ©  opp  7^  this  © 

unpacked(opp@|  parentO)  ©  3  oppp,  Iccc,  kk.  opp.parent  oppp  ©  opp  7^  oppp  © 
unpacked(opp@^  count(lccc))  ©  3  oil,  lie.  opp@^  left(oll,  lie)  © 

^(oppp  7^  null  ^  oppp @kk parentO  ©  (oppp@|  left(opp,  Iccc)  ©  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  © 

©  opp@  I  parentO  © 

opp@l  right(this,  Icc)  © 

unpacked(this@^  count(lcc))  © 

3  ol,  Ic,  or,  rc. 

this®  I  right(or,  rc)  ©this@|  left(ol,  Ic)  } 


unpack  opp  from  right(this,  Icc) 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentO)  ® 
this. parent  ^  opp  ©  opp  ^  this  © 

unpacked(opp@|  parentO)  ©  3  oppp,  Iccc,  kk.  opp.parent  oppp  ©  opp  7^  oppp  © 
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unpacked(opp@^  count(lccc))  0  3  oil,  11c.  opp@^  left(oll,  11c)  0 

^(oppp  ^  null  ^  oppp@kk  parentO  0  (oppp@^  left(opp,  Iccc)  0  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))j  0 
0  opp@  I  parentO  0 

unpacked(opp@l  right(this,  Icc))  0 
opp.right  this  0  this@^  count(lcc)  0 

unpacked(this@^  count(lcc))  0 
3  ol,  Ic,  or,  rc. 

this@^  right(or,  rc)  0this@^  left(ol,  Ic)  } 


pack  this  @  ^  count(lcc),  add  it  to  the  other  half 
then  unpack  the  count  predicate 
{3  k1 ,  opp,  Icc,  k. 
unpacked(ttiis@kl  parentO)  ® 

this. parent  ^  opp  0  opp  ^  this  0 

unpacked(opp@|  parentO)  0  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  7^  oppp  0 

unpacked(opp@^  count(lccc))  0  3  oil,  11c.  opp.count  — Iccc  0  Iccc  =  lie  +  Icc  +  1  0  opp@ 
left(oll,  11c)  0 

^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@^  left(opp,  Icec)  0  oppp@^  right(opp,  Icee))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

unpacked(opp@l  right(this,  Icc))  0 
opp.right  ^  this  0 

unpacked(ttiis@l  count(lcc))  0 
3  ol,  Ic,  or,  rc. 

this@^  right(or,  rc)  0this@^  left(ol,  Ic)  } 


this  .updateCountO; 
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toll-* 


{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parent())  ® 
this. parent  ^  opp  ®  opp  7^  this  0 

unpacked(opp@|  parentQ)  0  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  ^  oppp  0 

unpacked(opp@^  count(lccc))  0  3  oil,  11c.  opp.count  Iccc  0  Iccc  =  lie  +  Icc  +  1  0  opp@^ 
left(oll,  11c)  0 

^(oppp  7^  null  — o  oppp@kk parentO  0  (oppp@^  left(opp,  Iccc)  ©  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

unpacked(opp@  1  right(this,  Icc))  0 
opp.right  ^  this  0 

this@l  count(lcc)  } 


pack  opp  in  right(this,  Icc) 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentO)  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked(opp@|  parentO)  ®  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  7^  oppp  0 

unpacked(opp@|  count(lccc))  0  3  oil,  11c.  opp.count  — Iccc  0  Iccc  =  llc  +  Icc  +  1  0  opp@| 
left(oll,  llc)  0 

^(oppp  7^  null  ^  oppp @kk parentO  0  (oppp@|  left(opp,  Iccc)  ©  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))j  0 
0  opp@  I  parentO  0 

opp@l  right(this,  Icc)  0 

this®  I  count(lcc)  } 


this  .  parent  .  updateCountRec  () ; 
{3  k1 ,  opp,  Icc,  k,  k3. 
unpacked(this@kl  parentO)  ® 
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this. parent  ^  opp  ®  opp  7^  this  (g) 

unpacked(opp@|  parent())  0  3  oppp,  Iccc,  kk.  opp.parent  oppp  0  opp  7^  oppp  0 

^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@^  left(opp,  Iccc)  0  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))j  0 

opp@^  right(this,  Icc)  0 

this@^  count(lcc)  0 
opp@k3  parentO  } 


pack  opp  in  parent() 

{3  k1 ,  opp,  Icc,  k,  k3. 
unpacked(this@kl  parentO)  ® 
this. parent  ^  opp  0  opp  ^  this  0 

unpacked(opp@|  parentO)  ®  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  7^  oppp  0 

^(oppp  7^  null  ^  oppp@kk  parentO  ®  (oppp@^  left(opp,  leec)  0  oppp@^  right(opp,  leee))) 

© 

(oppp  =  null  ^  opp@|  count(lcee))^  0 

opp@|  right(this,  lee)  0 

this@^  count(lcc)  0 
opp@k3  parentO  } 


pack  this  in  parent(),  assuming  opp  is  not  null. 

It’s  not  since  we  just  called  updateCountRec  on  it,  we  are  on  that  branch. 

{3  kl.  this@kl  parentO) 

QED 

2. In  the  second  case  we  assume  it’s  the  left  child, 
instantiate  oil  =  this.  He  =  Icc;  merge  both  ^  to  opp  in  right 
{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentO)  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpaeked(opp@|  parentO)  0  3  oppp,  Iccc,  kk.  opp.parent  oppp  0  opp  7^  oppp  0 
unpacked(opp@^  count(lccc))  0  3  orr,  rrc.  opp. count  — )■  Iccc  0  Iccc  =  Icc  +  rrc  +  1  0  opp@^ 
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right(orr,  rrc)  0 


(^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@|  left(opp,  Iccc)  ©  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

opp@l  left(this,  Icc)  0 

unpacked(this@^  count(lcc))  0 
3  ol,  Ic,  or,  rc. 
this. count  Icc  0 

Icc  =  Ic  +  rc  +  1  0 

this@^  right(or,  rc)  0this@^  left(ol,  Ic)  } 


unpack  opp  from  left(this,  Icc) 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentQ)  0 
this. parent  ^  opp  0  opp  ^  this  0 

unpacked(opp@|  parentO)  ®  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  ^  oppp  0 

unpacked(opp@|  count(lccc))  0  3  orr,  rrc.  opp.COUnt  — ICCC  0  ICCC  =  rrc  +  Icc  +  1  0  opp@| 
right(orr,  rrc)  0 

^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@^  left(opp,  Iccc)  ©  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

unpacked(opp@l  left(this,  Icc))  0 
opp.left  ^  this  0  this@^  count(lcc)  0 

unpacked(this@^  count(lcc))  0 
3  ol,  Ic,  or,  rc. 
this. count  ^  Icc  0 
Icc  =  Ic  +  rc  +  1  0 

this @  I  right(or,  rc)  0this@^  left(ol,  Ic)  } 


pack  this  @  |  count(lcc),  add  it  to  the  other  half 
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then  unpack  the  count  predicate 
{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parent())  ® 
this. parent  ^  opp  ®  opp  ^  this  ® 

unpacked(opp@|  parent())  0  3  oppp,  Iccc,  kk.  opp.parent  oppp  0  opp  7^  oppp  0 

unpacked(opp@|  count(lccc))  0  3  orr,  rrc.  opp.count  — Iccc  0  Iccc  =  rrc  +  Icc  +  1  0  opp@| 
right(orr,  rrc)  0 

^(oppp  7^  null  ^  oppp@kk parentO  0  (oppp@|  left(opp,  Iccc)  0  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

unpacked(opp@l  left(this,  Icc))  0 

opp.left  ^  this  0 

unpacked(this@l  count(lcc))  0 
3  ol,  Ic,  or,  rc. 
this. count  ^  Icc  0 
Icc  =  Ic  +  rc  +  1  0 

this@^  right(or,  rc)  0this@^  left(ol,  Ic)  } 


this  .updateCountO; 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parentO)  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked(opp@|  parentO)  0  3  oppp,  Iccc,  kk.  opp.parent  oppp  0  opp  7^  oppp  0 

unpacked(opp@^  count(lccc))  0  3  orr,  rrc.  opp.COUnt  — ICCC  0  ICCC  =  rrc  +  Icc  +  1  0  opp@^ 
right(orr,  rrc)  0 

^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@|  left(opp,  Iccc)  ©  oppp@|  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

unpacked(opp@l  left(this,  Icc))  0 

opp.left  ^  this  0 
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this@l  count(lcc)  } 


pack  opp  in  left(this,  Icc) 

{3  k1 ,  opp,  Icc,  k. 
unpacked(this@kl  parent())  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked(opp@|  parent())  0  3  oppp,  Iccc,  kk.  opp.parent  ^  oppp  0  opp  /  oppp  0 

unpacked(opp@^  count(lccc))  0  3  orr,  rrc.  opp. count  —5-  Iccc  0  Iccc  =  rrc  +  Icc  +  1  0  opp@| 
right(orr,  rrc)  0 

^(oppp  7^  null  — o  oppp@kk parentO  0  (oppp@^  left(opp,  Iccc)  ©  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 
0  opp@  I  parentO  0 

opp@l  left(this,  Icc)  0 

this@^  count(lcc)  } 


this  .  parent  .updateCountRec  (); 


{3  k1 ,  opp,  Icc,  k,  k3. 
unpacked(this@kl  parentO)  0 
this. parent  ^  opp  0  opp  7^  this  0 

unpacked(opp@|  parentO)  ®  3  oppp,  Iccc,  kk.  opp.parent  oppp  0  opp  7^  oppp  0 

^(oppp  7^  null  ^  oppp@kk  parentO  0  (oppp@^  left(opp,  Iccc)  ©  oppp@^  right(opp,  Iccc))) 

© 

(oppp  =  null  ^  opp@|  count(lccc))^  0 

opp@|  left(this,  Icc)  0 

this@^  count(lcc)  0 
opp@k3  parentO) 

pack  this  in  parent)),  assuming  opp  is  not  null. 

It’s  not  since  we  just  called  updateCountRec  on  it,  we  are  on  that  branch. 

{3  kl.  this@kl  parentO) 

QED 
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else 


{  unpacked(this@kl  parent())  0  3  opp,  Icc.  unpacked(this@^  count(lcc))  0 
3  ol,  Ic.  this@i  left(l,  Ic)  0 
3  or,  rc,  Id .  this.count  ^  Icc  0 
Icc  =  Id  +  rc  +  1  0 
this®  I  right(or,  rc)  0 
this. parent  ^  opp  0 

opp  7^  this  0  opp  =  null  0  this@|  count(lcc)  } 


merge  this,  |  in  count{lcc)  from  packed  and  unpacked 
{  unpacked(this@kl  parent())  0  3  opp,  Icc.  unpacked(this@  1  count(lcc))  0 
3  ol,  Ic.  this®  I  left(l,  Ic)  0 
3  or,  rc.  Id .  this.count  ^  Icc  0 
Icc  =  Id  +  rc  +  1  0 
this®  I  right(or,  re)  0 
this. parent  ^  opp  0 
opp  7^  this  0  opp  =  null  } 


this  .  updateCount  0  ; 


{  unpacked(this®kl  parent())  0  3  opp,  Icc.  this®l  count(lcc)  0 
this. parent  ^  opp  0 
opp  7^  this  0  opp  =  null  } 

split  count  in  half  and  pack  this  in  parent 

{3  kl.  this®kl  parentO  } 

QED 

} 

private  void  updateCount  ( ) 

3  c,  d ,  c2,  ol,  or.  unpacked(this®l  count(c))  0 
this®^  left(ol,  cl)  0this®|  right(or,  c2) 

^  3  C.  this®l  count(c) 

{ 

int  newc  =  1; 

unpack  this  @^left(ol,c1 ) 

{  newc  =  1  0 

unpacked(this®  1  count(c))  0 


70 


unpacked(this@^  left(ol,  cl))  0 

this. left  ol  0  (ol  =  null  ^  c1  =  0)  0 

(ol  7^  null  ^  ol@7  count(cl))  0 
this®  I  right(or,  c2)  } 

if  (  this  .left  !=  null ) 

{  newc  =10 

unpacked(this@l  count(c))  0 
unpacked(this@^  left(ol,  cl))  0 

this. left  ol  0 

ol@|  count(cl)  0 
this®  I  right(or,  c2)  } 

unpack  ol  in  ^  count(c1) 

{  newc  =10 

unpacked(this@l  count(c))  0 
unpacked(this®  I  left(ol,  cl))  0 
this.left  ol  0 

unpacked(ol@|  count(cl))  0 
3  lol,lor,llc,lrc.  ol. count  ^  c1  0 
cl  =  11c  +  Ire  +  1  0 
ol®i  left(lol,  11c)  0 
ol®^  right(lor,  Ire)  0 
this  @7  right(or,  c2)  0} 

newc  =  newc  +  left,  count 
{  newc  =  1  +  cl  0 
unpacked(this®  1  count(c))  0 
unpacked(this®  I  left(ol,  cl))  0 
this.left  ol  0 
unpacked(ol®  ^  count(cl))  0 
3  lol,lor,llc,lrc.  ol. count  ^  c1  0 
cl  =  11c  +  Ire  +  1  0 

ol®^  left(lol,  11c)  0  ol®^  right(lor.  Ire)  0 
this®^  right(or,  c2)  } 

pack  ol  in  count(c1) 

{  newc  =  1  +  Ic  0 
unpacked(this®  1  count(c))  0 
unpacked(this®  ^  left(ol,  cl))  0 

this.left  ol  0 

ol®^  count(cl)  0 
this®^  right(or,  c2)} 

pack  this  in  left(ol,  c1) 

{  newc  =  1  +  cl  0 
unpacked(this®  1  count(c))  0 


this@^  left(ol,  cl)  0 
this@^  right(or,  c2)  } 

unpack  this  in  |  right(or,  c2) 

{  newc  =  1  +  c1  0 
unpacked(this@l  count(c))  0 
this@^  left(ol,  cl)  0 
unpacked(this@|  right(or,  c2))  0 
this. right  ^  or  0 
((or  7^  nuii  ^  or@^  count(c2))  © 

(or  =  nuii  ^  c2  =  0))  } 

if  (  this  .right  !=  null ) 

{  newc  =  1  +  c1  0 
unpacked(this@l  count(c))  0 
this@^  left(ol,  cl)  0 
unpacked(this@|  right(or,  c2))  0 
this.right  ^  or  0 
or@|  count(c2)  } 

unpack  or  in  |  count(c2) 

{  newc  =  1  +  cl  0 
unpacked(this@l  count(c))  0 
this@^  left(ol,  cl)  0 
unpacked(this@|  right(or,  c2))  0 
this.right  ^  or  0 
unpacked(or@^  count(c2))  0 
3  roi,ror,ric,rrc.  or.count  ^  c2  0 
c2  =  rlc  +  rrc  +  1  0 
or@|  left(rol,  rlc)  0 
or@|  right(ror,  rrc)  } 

newc  =  newc  +  right,  count; 
{  newc  =  1  +  c1  +  c2  0 
unpacked(this@l  count(c))  0 
this@^  left(ol,  cl)  0 
unpacked(this@^  right(or,  c2))  0 
this.right  or  0 
unpacked(or@^  count(c2))  0 
3  roi,ror,ric,rrc.  or.count  ^  c2  0 
c2  =  rlc  +  rrc  +  1  0 
or@|  left(rol,  rlc)  0 
or@|  right(ror,  rrc)  } 

pack  or  in  count 
{  newc  =  1  +  cl  +  c2  0 
unpacked(this@  1  count(c))  0 
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this@^  left(ol,  cl)  ® 
unpacked(this@|  right(or,  c2))  0 
this. right  or  0 
or@^  count(c2)  } 

pack  this  in  right 
{  newc  =  1  +  c1  +  c2  0 
unpacked(this@l  count(c))  0 
this@^  left(ol,  cl)  0 
this@^  right(or,  c2)  } 

this. count  =  newc ; 

{  newc  =  1  +  c1  +  c2  0 
unpacked(this@l  count(c))  0 
this. count  ^  c  0  c  =  newc  0 
this@^  left(ol,  cl)  0 
this®  I  right(or,  c2)  } 

pack  this  in  count(newc) 

{  this@l  count(newc)  } 

QED 


} 

public  void  setLeft  (Composite  1) 
this  7^  I  0 

3fcl,  /c2.(this@kl  parentO  0  l@k2  parent()  ^ 

3  k.this@k  parentO 

{ 

unpack  I  from  parent 

{  unpacked(l@k2  parentO)  0  3  op,  Ic,  k,k1  ,k3. 1. parent  op  0 

op  7^  I  0  1®^  count(lc)  0 

(^(op  7^  null  ^ 

op®k3  parentO  C) 

(op@^  left(l,  Ic)  © 
op®  I  right(l,  Ic)))  © 

(op  =  null  ^  1®|  eount(lc))  j  0  this  7^  I  0 
this®kl  parentO  } 

{  unpacked(l@k2  parentO)  C>  3  Ic,  k1 .  I. parent  — )■  null  0 
null  7^  I  0  1®7  count(lc)  0 
1®|  eount(lc)  0  this  7^  I  0 
this®kl  parentO  } 

1  .  parent  =  this; 
assignment  rule 
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{  unpacked(l@k2  parentQ)  0  3  Ic.  I. parent  — )■  this  ® 
null  ^  I  (8)  count(lc)  0 
1@|  count(lc)  ®  this  ^  i  0 
this@kl  parentO  } 

unpack  this  from  parent 

{  unpacked(l@k2  parent())  0  unpacked(this@kl  parent())  0  3  opp,  icc,  k,k4.  this. parent 
^  opp  0 

opp  ^  this  0  this®  I  count(icc)  0 
^(opp  ^  nuii  ^ 
opp@k4  parentO  ® 

(opp®^  left(this,  icc)  © 
opp®  I  right(this,  icc)))  © 

(opp  =  nuii  ^  this®^  count(icc))  ^  0 
3  ic.  i. parent  this  0 

null  7^  i  0  1®^  count(ic)  0 
1®^  count(ic)  0  this  7^  i  } 

unpack  this  from  |  count(icc) 

{  unpacked(l®k2  parentO)  0  unpacked(this®kl  parentO)  0  3  opp,  icc,  k.  unpacked(this®  ^ 
count(lcc))  0  3  oi,  iic,  or,  rc.  this. count  icc  0 

icc  =  iic  +  rc  +  1  0 
this®  I  left(ol,  lie)  0 
this®^  right(or,  rc)  0 

this. parent  ^  opp  0 
opp  7^  this  0 
(^(opp  7^  nuii  ^ 

opp®  I  parentO  0 
(opp®  I  left(this,  icc)  © 
opp®  I  right(this,  icc)))  © 

(opp  =  nuii  ^  this®^  count(icc))  ^  0 

3  ic.  i. parent  ^  this  0 

null  7^  i  0  1®^  count(ic)  0 
1®^  count(ic)  0  this  7^  i  0 
this®  I  left(null,  0)  } 

existentiaiize  oi  with  nuii  and  iic  with  0  (to  unify  ieft  permissions) 

{  unpacked(l®k2  parentO)  ®  unpacked(this®kl  parentO)  ®  3  opp,  icc,  k.  unpacked(this®  ^ 
count(lcc))  0  3  or,  rc.  this. count  -)■  icc  0 
icc  =  0  +  rc  +  1  0 

this®^  right(or,  rc)  0 
this. parent  ^  opp  0 


74 


opp  7^  this  0 
(^(opp  7^  null  ^ 
opp@k4  parentO  ® 

(opp@|  left(this,  Icc)  © 
opp@i  right(this,  Icc)))  © 

(opp  =  null  ^  this@^  count(lcc))  ^  ® 

3  Ic.  I. parent  this  © 
null  7^  I  ©  1@^  count(lc)  © 
count(lc)  ©  this  7^  I  } 
merge  the  half  fractions  to  left 

{  unpacked(l@k2  parent())  ©  unpacked(this@kl  parent())  ©  3  opp,  Icc,  k.  unpacked(this@  ^ 
count(lcc))  © 

this. left  -)►  null  ©  3  or,  rc.  this. count  Icc  © 

Icc  =  0  +  rc  +  1  © 
this@^  right(or,  rc)  © 
this. parent  ^  opp  © 
opp  7^  this  © 

(^(opp  7^  null  ^ 

opp@k4  parentO  © 

(opp@^  left(this,  Icc)  © 
opp@i  right(this,  Icc)))  © 

(opp  =  null  ^  this@i  count(lcc))  ^  © 

3  Ic.  I. parent  this  © 
null  7^  I  ©  1@|  count(lc)  © 

1@^  count(lc)  ©  this  7^  I  } 

this .left  =  1 ; 

assignment 

{  unpacked(l@k2  parentO)  ©  unpacked(this@kl  parentO)  ©  3  opp,  Icc,  k.  unpacked(this@ | 
count(lcc))  © 

this. left  ^  I  ©  3  or,  rc.  this.count  Icc  © 

Icc  =  Ic  +  rc  +  1  © 
this®  I  right(or,  rc)  © 
this. parent  opp  © 
opp  7^  this  © 

(^(opp  7^  null  ^ 

opp@k4  parentO  © 

(opp®^  left(this,  Icc)  © 
opp®^  right(this,  Icc)))  © 
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(opp  =  null  ^  this®  I  count(lcc))  j  0 
3  Ic.  I. parent  this  0 
null  7^  I  0  1®^  count(lc)  0 
1®|  count(lc)  0  this  7^  I  } 
pack  this  in  left(l,  Ic) 

{  unpacked(l®k2  parent())  0  unpacked(this®kl  parent())  0  3  opp,  Icc,  k.  unpacked(this®  | 
count(lcc))  0 
3  Ic.  this@l  left(l,  Ic)  0 
3  or,  rc.  this.count  ^  Icc  0 
Icc  =  Ic  +  rc  +  1  0 
this®^  right(or,  rc)  0 
this. parent  ^  opp  0 
opp  7^  this  0 
(^(opp  7^  null  ^ 
opp®k4  parentO  0 
(opp®^  left(this,  Icc)  © 
opp®^  right(this,  Icc)))  © 

(opp  =  null  ^  this®  I  count(lcc))  ^  0 
I. parent  this  0 

null  7^  I  0 

1®^  count(lc)  0  this  7^  I  } 

this.  updateCountRec  ( ) ; 

{  3  k1 ,  k2,  Ic.  unpacked(l®k2  parentO)  0 
this®^  left(l,  Ic)  0 
I. parent  -)■  this  0 
null  7^  I  0 
this®kl  parentO 
1®^  count(lc)  0  this  7^  I  } 
pack  I  in  parentO 

{3  k1 ,  k2.  I®k2  parentO  0  this®kl  parentO) 

QED 

} 

} 


11  Related  Work 

There  are  two  main  lines  of  research  that  give  partial  solutions  for  the  verification  of  object-oriented 
code  in  the  presence  of  aliasing:  the  permission-based  work  and  the  separation  logic  approaches. 

Bierhoff  and  Aldrieh  [3]  developed  access  permissions,  an  abstraction  that  combines  typestate 
and  objeet  aliasing  information.  Developers  use  aecess  permissions  to  express  the  design  intent  of 
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their  protocols  in  annotations  on  methods  and  classes.  Our  work  is  a  generalization  of  their  work, 
as  we  use  object  propositions  to  modularly  check  that  implementations  follow  their  design  intent. 
The  typestate  [7]  formulation  has  certain  limits  of  expressiveness:  it  is  only  suited  to  finite  state 
abstractions.  This  makes  it  unsuitable  for  describing  fields  that  contain  integers  and  can  take  an 
infinite  number  of  values  and  can  satisfy  various  arithmetical  properties.  Our  object  propositions 
have  the  advantage  that  they  can  express  predicates  over  an  infinite  domain,  such  as  the  integers. 

Access  permissions  allow  predicate  changes  even  if  objects  are  aliased  in  unknown  ways. 
States  and  fractions  [5]  capture  alias  types,  borrowing,  adoption,  and  focus  with  a  single  mech¬ 
anism.  In  Boyland’s  work,  a  fractional  permission  means  immutability  (instead  of  sharing)  to 
ensure  non-interference  of  permissions.  We  use  fractions  to  keep  object  propositions  consistent 
but  track,  split,  and  join  fractions  in  the  same  way  as  Boyland. 

Boogie  [1]  is  a  modular  reusable  verifier  for  Spec#  programs.  It  provides  design-time  feedback 
and  generates  verification  conditions  to  be  passed  to  an  automatic  theorem  proven  While  Boogie 
allows  a  client  to  depend  on  properties  of  objects  that  it  owns,  we  allow  a  client  to  depend  on 
properties  of  objects  that  it  doesn’t  own,  too. 

Krishnaswami  et  al.  [17]  show  how  to  modularly  verify  programs  written  using  dynamically- 
generated  bidirectional  dependency  information.  They  introduce  a  ramification  operator  in  higher- 
order  separation  logic  that  explains  how  local  changes  alter  the  knowledge  of  the  rest  of  the  heap. 
Their  solution  is  application  specific,  as  they  need  to  find  a  version  of  the  frame  rule  specifically 
for  their  library.  Our  methodology  is  a  general  one  that  can  potentially  be  used  for  verifying  any 
object-oriented  program. 

Nanevski  et  al.  [20]  developed  Hoare  Type  Theory  (HTT),  which  combines  a  dependently 
typed,  higher-order  language  with  stateful  computations.  While  HTT  offers  a  semantic  framework 
for  elaborating  more  practical  external  languages,  our  work  targets  Java-like  languages  and  does 
not  have  the  complexity  overhead  of  higher-order  logic. 

Summers  and  Drossopoulou  [24]  introduce  Considerate  Reasoning,  an  invariant-based  verifi¬ 
cation  technique  adopting  a  relaxed  visible-state  semantics.  Considerate  Reasoning  allows  distin¬ 
guished  invariants  to  be  broken  in  the  initial  states  of  method  executions,  provided  that  the  methods 
re-establish  the  invariant  in  the  final  state.  The  authors  demonstrate  Considerate  Reasoning  based 
on  the  Composite  pattern  and  provide  the  encoding  of  their  technique  in  the  Boogie  intermediate 
verification  language  [1],  facilitating  the  automatic  verification  of  the  Composite  pattern  specifi¬ 
cation.  Despite  the  fundamental  differences  in  underlying  methodology  (visble-state  invariants  vs. 
abstract  predicates)  and  logic  between  Considerate  Reasoning  and  our  approach,  there  are  interest¬ 
ing  analogies  in  the  specification  of  the  Composite  pattern.  For  instance,  the  method  that  triggers 
the  bottom-up  traversal  of  the  Composite  to  update  a  composite’s  count  field  in  the  Considerate 
Reasoning  specification  does  not  expect  the  composite  invariant  in  the  method’s  initial  state.  This 
is  similar  to  our  method  updateCountRec()  which  requires  the  predicates  parent  and  count  to  be 
unpacked. 

Cohen  et  al.  [6]  use  locally  checked  invariants  to  verify  concurrent  C  programs.  In  their 
approach,  each  object  has  an  invariant,  a  unique  owner  and  they  use  handles  (read  permissions)  to 
accommodate  shared  objects.  The  disadvantage  is  their  high  annotation  overhead  and  the  need  to 
introduce  ghost  fields.  We  do  not  have  to  change  the  code  in  order  to  verify  our  specifications. 
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Our  work  uses  abstract  predicates,  similar  to  the  work  of  Parkinson  and  Bierman  [21]  and 
Dinsdale- Young  et  al.  [8].  The  abstraction  makes  it  easy  to  change  the  internal  representation 
of  a  predicate  without  modifying  the  client’s  external  view  of  it.  The  main  mechanism  is  still 
separation  logic,  with  its  shortcomings.  Unlike  separation  logic,  we  permit  sharing  of  predicates 
with  an  invariant-based  methodology.  This  avoids  non-local  characterizations  of  the  heap  structure, 
as  required  (for  example)  in  Bart  Jacob’s  Composition  pattern  solution  [15]. 

There  exist  a  set  of  verification  methodologies  for  object-oriented  programs  in  a  concurrent 
setting:  [8,  14,  19,  16].  These  approaches  can  express  externally  imposed  invariants  on  shared 
objects,  but  only  for  invariants  that  are  associated  with  the  lock  protecting  that  object.  In  many 
cases,  it  may  be  inappropriate  to  associate  such  an  invariant  with  the  lock:  for  example,  in  a 
singlethreaded  setting,  there  is  no  such  lock.  Even  in  multithreaded  settings,  a  high  level  lock  may 
protect  a  data  structure  with  internal  sharing,  in  which  case  specifying  that  sharing  in  the  lock 
would  break  the  modularity  of  the  data  structure.  Thus,  these  systems  do  not  provide  an  adequate 
solution  to  the  modular  verification  problem  we  consider. 


12  Conclusion 

We  have  introduced  the  novel  abstraction  object  proposition,  which  uses  abstract  predicates  to 
describe  properties  of  objects,  and  fractions  to  describe  the  aliasing  between  objects.  We  used 
object  propositions  to  write  the  specification  and  formally  prove  the  correctness  of  an  instance  of 
the  Composite  pattern.  We  proved  our  system  to  be  sound  and  highlighted  the  ways  in  which  it 
improves  the  state  of  the  art  in  the  verification  of  object-oriented  code. 
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